Librepgp-01 (was: Updated PQC specification)

[Andrew Gallagher]

Hi, Werner.

I recently noticed the following section of the librepgp draft and was curious:

> 5.2.3.17. Revocation Key
> (1 octet of class, 1 octet of public-key algorithm ID, 20 or 32 octets of fingerprint)
> V4 keys use the full 20 octet fingerprint; V4 keys with the class octet bit 0x20 set use the extended 32 octet v4 fingerprint; V5 keys use the full 32 octet fingerprint.

This appears to have been changed between rfc4880bis-10 and librepgp-00, to introduce the “extended 32 octet v4 fingerprint”, which is undefined elsewhere in the draft (that I can see). I only noticed this on reading libregpg-01, as it doesn’t appear to have been discussed on any of the lists so far.

I assume this new “extended fingerprint” has been introduced so that v4 keys can be referred to by a sha2-256 digest rather than a sha-1 fingerprint, thus maintaining modern cryptographic strength. I wonder though how a v4 key will be located using the “extended fingerprint”? Do you intend to create two fingerprints for all v4 keys and index both? Or do you look up the supposed revocation key via the subpackets in the revocation signature itself, download it and then calculate its extended fingerprint to verify that it corresponds? The second method seems to involve extra lookups at signature verification time, whereas the first would allow the revocation key to be obtained in advance and cached locally, which would be more efficient.

I bring this up now because a similar issue has recently arisen re balancing the need for a unique identifier for old keys with the need for a strong cryptographic binding at all times, in https://gitlab.com/andrewgdotcom/draft-gallagher-openpgp-replacementkey/-/issues/10 - in this case we have decided to use both the v4 fingerprint (for easy identification) AND a strong hash over the same material (which I call the “imprint”, but which is similar in construction to your “extended fingerprint”). This is slightly uglier on the wire, but doesn’t sacrifice either of the design goals.

Have I understood the intent of this section correctly?

Thanks,
A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://librepgp.org/pipermail/librepgp-discuss/attachments/20240620/f5bab954/attachment.sig>