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

may be related to https://dev.gnupg.org/T5957#163468

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;

API which does not require allocation internally would be better. In this case, it is allocated on stack by the caller.

I mean, something like this (for GNU/Linux):

diff --git a/src/misc.c b/src/misc.c
index 4db2d9a4..74864334 100644
--- a/src/misc.c
+++ b/src/misc.c
@@ -577,3 +577,80 @@ _gcry_divide_by_zero (void)
     gpg_err_set_errno (EDOM);
     _gcry_fatal_error (gpg_err_code_from_errno (errno), "divide by zero");
 }
+
+#ifdef HAVE_CLOCK_GETTIME
+#include <time.h>
+# if defined(CLOCK_THREAD_CPUTIME_ID) && defined(CLOCK_TAI)
+struct gcry_timedwait
+{
+  struct timespec ts;
+};
+
+typedef struct gcry_timedwait *gcry_timedwait_t;
+
+gcry_err_code_t
+_gcry_timedwait_new (gcry_timedwait_t *r_tw, unsigned int flags)
+{
+  gcry_err_code_t err;
+  gcry_timedwait_t tw;
+
+  *r_tw = NULL;
+
+  /* Possibly, it would be good to be able to select the wall clock.
+   * For now, it's CPU time by the thread.  */
+  if (flags != 0)
+    return GPG_ERR_INV_ARG;
+
+  tw = xtrymalloc (sizeof (gcry_timedwait_t));
+  if (!tw)
+    return gpg_err_code_from_syserror ();
+
+  if (clock_gettime (CLOCK_THREAD_CPUTIME_ID, &tw->ts) < 0)
+    {
+      err = gpg_err_code_from_syserror ();
+      xfree (tw);
+      return err;
+    }
+
+  *r_tw = tw;
+  return 0;
+}
+
+gcry_err_code_t
+_gcry_timedwait_release (gcry_timedwait_t tw, struct timespec ts_r)
+{
+  gcry_err_code_t err;
+  struct timespec ts;
+  u32 negative;
+
+  if (clock_gettime (CLOCK_THREAD_CPUTIME_ID, &ts) < 0)
+    {
+      err = gpg_err_code_from_syserror ();
+      xfree (tw);
+      return err;
+    }
+
+  ts.tv_sec -= tw->ts.tv_sec;
+  ts.tv_nsec -= tw->ts.tv_nsec;
+  negative = ((u32)ts.tv_nsec) >> 31;
+  ts.tv_sec -= negative;
+  ts.tv_nsec += (1000000000 * negative);
+
+  xfree (tw);
+
+  ts_r.tv_sec -= ts.tv_sec;
+  ts_r.tv_nsec -= ts.tv_nsec;
+  negative = ((u32)ts_r.tv_nsec) >> 31;
+  ts_r.tv_sec -= negative;
+  ts_r.tv_nsec += (1000000000 * negative);
+
+  if (ts_r.tv_sec < 0)
+    return GPG_ERR_TIME_CONFLICT;
+
+  if (clock_nanosleep (CLOCK_TAI, 0, &ts_r, &ts_r))
+    return gpg_err_code_from_syserror ();
+
+  return 0;
+}
+# endif
+#endif

Wit the test keys posted in T7014 it is now possible to decrypt the sample data. The test data has been slightly adjusted for the new format; see

This is a KDE bug and not really appropriate for this tracker.

Alexander suggested that we could avoid another window by putting check boxes in the revocation window for automatically uploading to the configured keyserver and creating a public key export with the revocation. That could then be configurable via the registry on windows, so that companies could adapt that according to their SOP.

In T6813#184976, @ebo wrote:

Works on Gpg4win 4.3.1, too.

But noticed an inconsistency for the key creation via GpgOL: Contrary to the behavior for key creation in Kleopatra in Gpg4win, you are asked for a password for the new key.

Works on Gpg4win 4.3.1, too.

That said I think we should then strive to use only one "next" window.

Revocations are an exceptional task and rarely needed. In this case ("help, help , my key is compromised, what shall I do now?") an extra dialog to help the user is imho appropriate. This different for the key generation process, becuase this needs to be done by every user at least once and thus should be UI-wise as simple as possible.

This is a KDE bug and not really appropriate for this tracker.

I had wrong interpretation about symmetric cipher algorithm identifier in the draft. It specifies symmetric cipher for the following Symmetrically Encrypted Data Packet (I was wrongly interpret as if it were specifying algo for AES keywrap).

@werner I- think you were a bit quick on the trigger to shut this down.
I had rebooted the machine in between attempts. So your analysis is actually not correct.
Basically you have an issue that something in gpg is using something in a locale that is not installed. I pretty much proved that.
Anywho, I'll leave it to you to work out if you want to bother investigating it further.

"Today" was already removed together with other changes for T6621: Kleopatra: Remove "in n days/weeks/months/years" input from Change Validity Period dialog.

I just want to point out that we have explicitly decided to remove confronting the user with five different "What next" options in the certificate creation workflow. One reason is that the choice overwhelms the users because some think they need to do everything. Another reason is that many options were completely wrong for some of our customers. Such workflows are much better documented in company-specific SOPs (standard operation procedures).

Fixed. This improves the first impression when users use the first smart card with Kleopatra.