There are multiple problems described in your report. Let us handle one by one.

• I confirmed that mistakes in GnuPG. There are data where constructed Data Objects are specified as primitive (data_objects in app-openpgp.c).
  • I'll fix this. So far, this doesn't cause any real problem though.

• Possible problem of OpenPGP card implementation(s) for the OpenPGP card specification
  • Whether or not the tag+length should be returned for the constructed TLV, for GET DATA command.

• GnuPG scdaemon behavior
  • It assumes that no tag+length for the data object F9

For the content of the DO (F9), card just stores the data content. It's GnuPG scdaemon (host side) to use the data to compute KEK (key encryption key) using KDF (key derivation function) when a user inputs his passphrase.

Given the situation where GnuPG works well with existing OpenPGP card implementations, what we should do here is, perhaps:

• Allowing correct implementation which returns tag+length for F9 data objects for GET DATA command

Please keep in mind, that it is not only about GnuPG and the OpenPGP card, but also between GnuPG and other PGP applications. I'm not really sure what the recent commit is doing, if it only affect the reading or also the writing of the data. But IMHO GnuPG should stick to the standard also if writing the KDF DO data because eventually, it will be used for authentication with the card.

There are three cases:

1. KDF DO stores the F9 tag+length (correct behavior, according to the standard)
2. KDF DO stores just the content (old behavior)
3. everything else, basically KDF DO stores garbage, ("The KDF-DO may be empty (set to NONE) or has an invalid value, in that case the standard password format (UTF-8) is valid.")

To be backwards compatible I'd propose the following: Store the KDF in the same format as it is already present on the card. For (3) use the new format, maybe ask the user first or make it an expert option.

I'll fix this. So far, this doesn't cause any real problem though.

Most probably, because of case (3) this will be overwritten with (2). FWIW, I stumbled across this because with my card, there is an option to enable KDF by default; it is a workaround for a card erratum for how the PINs are handled.

Allowing correct implementation which returns tag+length for F9 data objects for GET DATA command

And yes, this will probably fix my issue. I'll give it a try later. Just to confirm, all what is needed is the referenced commit? But again, GnuPG should adhere to the standard for interoperability with other PGP applications. But that is up to you to decide.

Please keep also in mind that the OpenPGP card specification has always and is still developed along with GnuPG . Thus if there are any uncertainties in the specification GnuPG's way of handling thing is the way to go. If there is a way to chnage things without risking any breakage we can of course fix that. In all other cases we need to continue wit the current way. For larger changes in the spec we can of course cleanup stuff - Achim is currently reworking on a revision.

I'm considering applying the following patch. With this change, scdaemon will works well with a card implementation which consider F9 (wrongly) as primitive data object, as well as correct card implementation.

diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
index 26ac91ea2..09223ce33 100644
--- a/scd/app-openpgp.c
+++ b/scd/app-openpgp.c
@@ -410,6 +410,10 @@ get_cached_data (app_t app, int tag,
   size_t len;
   struct cache_s *c;
   int exmode;
+  int do_constructed = 0;
+
+  if ((tag < 0x0100 && (tag & 0x20)) || (tag >= 0x0100 && (tag & 0x2000)))
+    do_constructed = 1;
 
   *result = NULL;
   *resultlen = 0;
@@ -452,6 +456,51 @@ get_cached_data (app_t app, int tag,
   err = iso7816_get_data (app_get_slot (app), exmode, tag, &p, &len);
   if (err)
     return err;
+
+  /* When Data Object is constructed, remove its tag and length before
+     storing it into the cache.  This handling also works well with
+     the card implementation which doesn't include its tag and length
+     for the DO value returned by GET DATA.  */
+  if (do_constructed)
+    {
+      if (len && tag < 0x0100 && p[0] == tag)
+        {
+          if (len >= 2 && p[1] < 0x80 && p[1] == len - 2)
+            {
+              len -= 2;
+              memmove (p, p+2, len);
+            }
+          else if (len >= 3 && p[1] == 0x81 && p[2] == len - 3)
+            {
+              len -= 3;
+              memmove (p, p+3, len);
+            }
+          else if (len >= 4 && p[1] == 0x82 && ((p[2] << 8) | p[3]) == len - 4)
+            {
+              len -= 4;
+              memmove (p, p+4, len);
+            }
+        }
+      else if (len >= 2 && tag >= 0x0100 && ((p[0] << 8) | p[1]) == tag)
+        {
+          if (len >= 3 && p[2] < 0x80 && p[2] == len - 2)
+            {
+              len -= 3;
+              memmove (p, p+3, len);
+            }
+          else if (len >= 4 && p[2] == 0x81 && p[3] == len - 3)
+            {
+              len -= 4;
+              memmove (p, p+4, len);
+            }
+          else if (len >= 5 && p[2] == 0x82 && ((p[3] << 8) | p[4]) == len - 4)
+            {
+              len -= 5;
+              memmove (p, p+5, len);
+            }
+        }
+    }
+
   if (len)
     *result = p;
   *resultlen = len;

FWIW, I've tested this patch and it works fine with both KDF as a constructed tag and as a primitive tag.

@mwalle Thank you for your testing.
Applied to master.
After testing, I'll also apply to 2.4 branch.