Thanks for that summary.

Since it seems there is a renewed interest in adding ECC support to GpgSM (as indicated by the T4098 feature request), I would like to write down here more details about this task.

See also T4013 which is about ed25519 key support

werner,
I'm the spanish user. Are you also setting default ocsp responder option?
Setting only ocsp_signer doesn't worked, there are several CA's with diferent ocsp responders.

The reporter said that it did not work for him.

A list of SHA-1 fingerprints for the valid certificates. With our without colons.

@werner what should the contents of the file look like?

I had to look it up in the code and man page too ;-)

Good to know. I thought that ocsp-signer was only used if ocsp-responder is explitly set. I've suggested the workaround in the Message Board.

Is using

In Wald someone reports that this also appears to happen when decrypting. https://wald.intevation.org/forum/message.php?msg_id=6377 Probably run-threaded will help to flush this out.

The original reporter in the gpg4win-forums reports that this does not work reliably. :-/

Gpg4win-3.1.3 was released.

We have a progress dialog now and only show details on request. I've also fixed a bug that you could trigger learning the keys twice which lead to undefined behavior.

Hi,
Can I ask if there is any update on the issue that I face?

Ok
Thanks for your answer

There is currently no ECC key support in the S/MIME component of Gpg4win. I've edited the task a bit to reflect that. So it is impossible to generate an ECC Key for S/MIME with Kleopatra.

I can't reproduce this. When I make Dirmngr offline I correctly get a No CRL known error. So it must be something different.

Tester reports that this works now.

I got feedback from the user that had the problem. It's fixed with 2.2.9 which contains your commit afaik.