[openpgp] Re: v4+v6

> 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 [...]

I'm not sure about the vice-versa part. My instinct would tell me there might be dragons when "downgrading" a v6 certificate into a v4 one, even though I cannot come up with a concrete idea for an attack. So treat this as just an articulation of my gut feelings :D

All in all its a nice idea, although its not universally applicable to all certs (e.g. legacy/weak keys).
Also, some popular key types (legacy x25519, legacy ed25519) MUST NOT be used with v6, so I guess you'd transform them to the new key type, which is no longer a bijection, as the v4 cert might also use the new non-legacy algorithms.

Still, its an interesting idea I'd say is worth further exploring.

Paul

Am 9. Februar 2025 14:41:54 MEZ schrieb "Neal H. Walfield" <[email protected]>:
>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]

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