@werner Yes, that sounds great, and would help already a lot, but extending it for card keys would be optimal. Thanks for your work.

In master (to be 2.3) you can add a Label: line into the sub key file of on-disk keys. I use this for quite some time now to show me alabel for my on-disk ssh keys so that I known which one was requested. We can and should extend this to card keys.

Same here, having YubiKeys and on-disk ssh keys from several computers, it is a bit a pain not to know which key is actually used. Any chances to get at least an update via manual editing of the comment?

In T4475#124816, @werner wrote:

Put

log-file /somewhere/scd.log
debug ipc,cardio
verbose

into ~/.gnupg/scdaemon.conf and kill scdaemon. Then look at the output. I would suggest to first stop the pcscd so that GnuPG's internal CCID driver will be used. Make also sure that there is no a permission problem with the usb port. In case of a CCID (card reader protocol) problem a

debug-ccid-driver

in scdaemon.conf will also be helpful.

The feature has been implemented for the -qt, -tqt, -gtk, and -curses pinentries.

In T2300#90092, @aheinecke wrote:

Ah nevermind. I think myself that this is nobug and current behavior is correct.

To implement / test the "not literally RFC compliant but in practice better" behavior let us call this now a wish and feature request as there are certificates in the wild other then intevation's and customers in large institutions run into that.

As far as I know this works.

This works but might have created a regression which is tracked in T4701

I give this normal priority even if it is a whish because I have the same whish and already have some code around that would make it more comfortable, especially if it is used directly in GpgOL.

I still would like to test this some more and work on it. I think the implemnation might still be a bit fragile.

Here is an example containing such a Attestation Signature:

BTW: I have the problem that I want to know the keys of all cards. "getinfo card_list" along with --demand can be used for this. gpg-card works this way. It does not work if plug in addtional cards becuase card_list shows only the cards for which a SERIALNO command has been used. A new feature to scan the buses for all readers and cards would be quite useful.

Still there are two places where we use "SCD serialno --demand <SERIALNO>". One is g10/skclist.c where we list available keys, another is the funciton card_key_available in agent/command-ssh.c .

By the change of rG9f39e0167d06: agent: Fix ask_for_card to allow a key on multiple cards., the SERIALNO in the stub is just an auxiliary information, not identifying the card. Now, it is the keygrip for key to identify/select the card.

Thanks for the detailed implemention plan. For the include-historic et al things it might be better to make use of the filter-syntax. I am not sure what is bets but that get clearer during coding. First step will be to add a parser and to silence 2.2 about this. I can imagine to later backport some basic functionality to 2.2

I did too many things at once.
I'm going to divide up into pieces.

PowerPC SHA-256 and SHA-512 implementations with little bit more tuning committed. Most notably, SHA-512 on POWER8 now gives similar performance to OpenSSL:

Patches send to mailing list:
https://lists.gnupg.org/pipermail/gcrypt-devel/2019-August/004800.html
https://lists.gnupg.org/pipermail/gcrypt-devel/2019-August/004799.html

I'll start working on PowerPC GHASH implementation in September after SHA2 is done.

I'll start working on new PowerPC SHA2 implementations for libgcrypt in coming weeks.

Patches for PowerPC AES acceleration sent to mailing-list, based partly on initial work by Shawn Landden (@slandden): https://lists.gnupg.org/pipermail/gcrypt-devel/2019-August/004788.html