On July, 19th, @werner wrote:

You need to wait a bit more.

@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.