[openpgp] v4+v6

Hi everyone,

I've been thinking recently about how to facilitate the transition
from v4 to v6 certificates.  This is not a new problem.  We've
discussed it on this list primarily in the context of Andrew's Key
Replacement document:

  https://www.ietf.org/id/draft-ietf-openpgp-replacementkey-03.html

but also at the last OpenPGP email summit:

  https://www.openpgp.org/community/email-summit/2024/minutes/#session-5-v4-to-v6-migration---kai

I have a different proposal, which is less ambitious than the key
replacement scheme in its scope.  Instead of linking certificates, we
use a one-to-one and onto function that maps a v4 certificate to a v6
certificate and vice versa.

The basic idea is as follows: when creating a certificate, instead of
creating a v4 or a v6 certificate, we create both using the same key
material, and the same meta-data (specifically the key creation time).

By using the same key material and the same meta-data, it is possible
to transform a v4 key packet into a v6 key packet and vica-versa, and
compute the corresponding fingerprint.  That is, given just a v4
certificate, we compute the corresponding v6 certificate by taking the
v4 certificate's primary key, interpreting it as a v6 key, and
computing the v6's fingerprint.  Then, we can look up the v6
certificate locally or in a remote directory.  The same is true in
reverse.

This construct has a few nice properties.

First, for a given v4 or v6 key, there is only one possible
corresponding v6 or v4 key, and it is straightforward to find it.  The
key replacement document has a number of safeguards to protect against
complicated certificate networks.  I haven't worked through them
completely, but I'm worried about the associated implementation
complexity.

Second, key equivalence is ipso facto trivial.  Given a v4 key and its
corresponding v6 key, whoever has the secret key material for the v4
key has the secret key material for the v6.  That is, the entity that
has access to the secret key material must be the same.  Therefore,
they can be treated as equivalent.

Consequently, if I can authenticate a user ID for a v4 certificate,
then I think it is reasonable to consider it authenticated for the
corresponding v6 certificate as well (modulo the crypographic policy).
In other words, the set of authenticated user IDs for the entity is
the union of those user IDs that can be authenticated for the v4
certificate and those user IDs that can be authenticated for the v6
certificate.

Further, checking one fingerprint is enough to authenticate both
certificates.  Thus when certifying a user ID for a v4 certificate, I
would simultaneously certify it for the v6 certificate.

Third, for people who use an OpenPGP card or something similar, they
still only need a single card.  Using this scheme, they won't need one
for their v4 certificate, and a different one for their v6
certificate.

Finally, the certificates can evolve separately.  If the ecosystem has
sufficiently evolved, it is possible to retire the v4 certificate
without retiring the v6 certificate.  The v4 and v6 certificates can
have different subkeys, and self-signed user IDs, but I think tools
should try to keep the certificates in sync.  For instance, when the
user adds a new self-signed user ID to one certificate, it should also
be added to the other.


This scheme works, because it it possible to use the same key material
for both v4 and v6 keys.  It works less well for PQC, but I think it
still partially works, because some PQC algorithms use a composite
scheme.

Given a certificate with an ML-DSA-65+Ed25519 primary key, (I think)
it is possible to extract just the Ed25519 public key, and compute the
corresponding v4 or v6 key.  So we can go from a PQC certificate to v4
or v6 certificate.

Given a v4 or v6 key, we can't figure out the fingerprint of the
corresponding PQC key, because we don't have the PQC public key.  But
if the PQC certificate is available, we can look it up by its Ed25519
public key.  This has a potential aliasing problem: multiple keys
could have the same Ed25519 public key.  But that can only be done by
the entity that controls the Ed25519 secret key material and not a
third-party: a third-party can create a new, valid PQC key, but since
they do not have access to the Ed25519 key, they can't create a valid
binding signature.


My main concern is whether the above scheme is safe: we're using the
same key material is two different contexts.  I hope somone who
understands the cryptography better than I do can comment.

Thoughts?

:) Neal

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]