GnuPG by design uses latest sub keys so in your setup office and home one
of them is latest.

The use case is having 2 different hardware tokens - I have an opengpg card which supports 4096 rsa subkeys, and a yubikey which supports 2048 rsa subkeys. At work I need one, at home the other.

After reading PIV and using PIV token I understood how much simple and easy
GnuPG is by design. You guys rock.

Is it you are moving to new sub keys? if yes do we still need outdated old
subkeys? Is it safe to cleanup old subkeys?

Hi, currently to be able to use 2 different cards with 2 different sets of subkeys from the same primary key (home and work) I need to manually delete ~/.gnupg/private-keys-v1.d/* everytime I want to switch from the first card to the second.

@bluca I created a ticket for smartcard, so that this ticket can focus on the issue of available keys on host. If anything, please add comment to T3416: gpg should select available signing key on card (even with -u option).

@gniibe yes, I can reproduce the problem using -u.
But why does picking a UID force the usage of the first known subkey? Is that expected behaviour? Is there a relationship between UIDs and subkeys?

I have updated D297: 785_sign-fix.patch patch to minimize the impact only to secret key lookup.

My change only addressed the use case with smartcard. So, I removed [TESTING] tag.

should be useful to create such completion stuff. No context specific completion but this is imho anyway a misfeature.

I've changed the text of this report from "filter" to "screener" to match the preferred terminology. thanks for the clarification.

I still consider the import screener (the term filter is used in a different way now) a big mess. Using the import feature to maintain the idea of a curated keyring is a bad idea because gpg has not been designed with this in mind. We spent so much time on this screener already and problems pop up again and again.

I think this is now resolved, as of rG926d07c5fa05

I am not proposing changing the order of the *hashed* subpackets in a signature. I'm proposing removing/changing/canonicalizing the *unhashed* subpackets in a signature. Sorry if i didn't make that clear enough in the initial message.

But wait. Does my idea really help with comparing? I doubt it because a signature also includes a date and other variable stuff and thus they are already binary identical or it is a different signature.

Right we can't change the order of signature subpackets after they have been created. Given that we create subpackets by directly appending them to a memory buffer instead of keeping a list of subpackets to create, the least invasive method would be a function to shuffle that memory buffer right before the signature is computed.

I thoroughly agree that this is not required by the specs.

Do you mean this?

That is not required by the specs. Another way is to provide a tool to compare keys. That seems to be easier to me. Also consider the cases that there are new new packets or signature subpackets with unknown properties to the current implementations. What about different encodings in signed key material?

The comment from aa above appears to be misdirected/spam.

@werner , I understand your poiont.

So, this is VERIFY reset allows the host to implement the "force" flag we always had in the card for the first key. At least kind of, because malware can still suppress the VERIFY reset ;-). The integrated "force" flag requires the admin PIN, which is malware should have more problems to snoop.

For the record, the authentication status reset by VERIFY command was introduced in OpenPGPcard specification V2.2.
I think V3 card supports that.
Gnuk 1.2 supports this reset feature.

Yes. For the use case of GnuPG, it is better to support disabling (unauthorize) use of keys.
On the other hand, IIUC, the original OpenPGPcard implementation is designed/implemented under the influence of other smartcard usages.

The idea with the smartcard is that you can limit the time of exposure
of the key. Leaving the card accessible to the host is thus not a good
idea. Malware can simply snoop the PIN from the last operation and
then, at its own discretion, use the keys of the card. This can only be
avoided by using a smartcard reader equipped with a pinpad and able to
filter commands so that it is not possible to bypass the pinpad (which
is easy for the host).

Unfortunately, not all OpenPGPcard implementations support command to unauthorize use of keys.

Using a smartcard it should be possible to set a cache-ttl value so that not only on-disk keys but also the PIN used for unlocking the key on the smartcard is not cached longer than the given period in cache-ttl. Until now you have to plug out and in the card by yourself to get this working. Alternatively you theoretically could set a config in scdaemon to power off the card after some time ("card-timeout). It could be a solution to set this config automatically if cache-ttl option is used.

Go ahead and type your message ...

Is this even something that we can control?

Smartcards and on-disk keys are very different things and handled by different processes.

I would also like this feature. I currently use a pair of subkeys (one for work one for personal projects) and it would be much easier if I could configure gpg-agent to append comments to the keys rather than displaying (none). Perhaps a flag could be added to sshcontrol which allows you to specify and arbitrary comment?

I have enabled login again and added the following login hint:
"Login via your Roundup account on bugs.gnupg.org has been disabled due to the migration to Phabricator. We apologise for any inconvenience caused. If you have previously used your Roundup account in this wiki, you can request a new password using the link above."

As part of switching debsig-verify from using --list-packets to gpg with --list-keys --with-colons and gpgv, it would be helpful to eventually be able to get the fingerprint instead of the keyid. This is needed because debsig-verify uses the keyid to select which one of its policy files it has to load, to apply for the subsequent actual verification of the .deb package.

This should be fixed by a0cc6e01. Just use the new gpgme_op_delete_ext operation with GPGME_DELETE_FORCE flag.

Werner indicated that the current behaviour is intentional.

GPGME does not use gpgv. What Justus likely meant is that we would need to change the common code used by gpgv and gpg. That may give problems in GPGME.

Can you describe the problems it would cause for gpgme? gpgme already currently expects that gpgv will return a failure for signatures made before the validity window of the key. so gpgme won't break just because gpgv is capable of returning a non-zero response.

Re-opening.

Implemented in c4506f624ed6854aa0ba1629aa2d1d43eb26900d.

We are in feature freeze and changing the status code of gpgv will likely cause problems for gpgme. We need to defer this.

I also have to add that, if this really has been resolved, it only covers up the case if the missing subkey(s) is/are on the smartcard(s), it does not solve the problem when none of the missing signing subkeys are in smartcards (as in, all on different computers). And it's clear that for version 2.1.22, it fails to get the available subkey on the disk for this case.

Done in a7bd2cbd.

@gniibe: I've tested 2.1.22 (from Debian experimental) and, while gpg --sign works, other programs (eg: git tag -s) still prompt to insert the card of the first signing subkey, despite the card with the second signing subkey being present.
Is that expected?

I implemented a possible fix in D442. The GnuPG Agent may call an external program (specified with the new --passphrase-checker option) to evaluate the passphrase's quality. This would allow to implement all kinds of metrics for passphrase strength, and to select one simply by choosing the right passphrase-checker.

Done in a8d0b8d23.

It's there in GnuPG 2.1 for a while, and bugs introduced by change were fixed.
So, I'm closing this bug.