Just as one data point, we (OpenPGP.js) have fully implemented v5 from
rfc4880bis, but always behind a flag with a stern warning that using it
may break compatibility in the future. So we are in principle fine with
doing so and changing the meaning of v5, indeed.
As an alternative option, if the only goal is to fix SHA1 fingerprints,
one thing that we have started doing internally at ProtonMail is giving
keys "SHA256 fingerprints", defined simply as calculating the
fingerprint but using SHA256 instead of SHA1. Obviously, for v5 keys
this is equivalent, but if we want, we could introduce this as a concept
for v4 keys in the crypto-refresh, and reserve v5 for a later spec.
We might then also want an "Issuer SHA256 Fingerprint" subpacket, and
allow it to be used for v4 keys as well. Similarly, we might want a
version 2 of the KDF parameters, indicating that SHA256 is to be used
for the fingerprint in the KDF. This would require modifying the public
key, somewhat diminishing the benefits, but at least the primary key
could remain the same. (I also don't think either of these are really
security-critical, compared to the main use case of identifying keys,
but I might be missing something.)
Obviously, there's then additional work to be done in the public APIs of
libraries, to expose SHA256 fingerprints, and making sure that people
(and applications) use that instead of the SHA1 fingerprint wherever
possible. Whether that is more or less work than transitioning from v4
to v5 keys, I'll leave up for debate :)
(If we want to give them a more user friendly name, we could call them
"long fingerprints", in contrast to "short key IDs" etc.)
Best,
Daniel
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp