[openpgp] Re: Review of draft-ietf-openpgp-replacementkey-04

Andrew Gallagher <[email protected]> Tue, 12 Aug 2025 12:19:46 +0100
Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>
Hi, Falko.

On 12 Aug 2025, at 11:15, Falko Strenzke <[email protected]> wrote:
> 
>> If an implementation links a particular identity (such as a User ID or a database record) to one primary key by a means other than Identity Equivalence, then it SHOULD treat that identity as being linked, in the same manner and to the same extent, with each other primary key in the same Identity Equivalence Set.
> 
> Does this say that if the original key contained a User ID Packet for User ID A and the replacement key (in the equivalence set) contains only a User ID Packet for a user ID B (different from A), that then an implementation should still treat the replacement key as valid for the user ID A? That's at least how I read it.

Yes.

> And I don't think that should happen. My point of view is that an identity claim from original to replacement (and vice versa) should only be transferable if the the same user ID (connected to that identity) is present in both certificates.

We don't require that a UID+self-cert exists for an identity claim to be valid, this is a direct (and intentional) consequence of allowing UIDless certificates in RFC9580. It would be strange to require the existence of a user ID on both certs for key replacement to work, but not for them to be directly usable.

Consider also that one of the design goals of key replacement was that the equivalence binding would be as closely analogous to subkey binding as possible. Subkeys are usable if their primary is usable and there is a valid, current subkey binding, so by design replacement keys are usable if the original is usable and there is a valid, current equivalence binding. Identity claims operate at a higher level in the stack.

>> Each such “derived" identity link is a subsidiary relationship of the original “direct" identity link.
>> If the same identity is directly linked into the Identity Equivalence Set by multiple identity claims, the derived link(s) are subsidiary to the strongest or most reliable direct link.
>> A derived identity link is otherwise independent of any identity claims over the other primary keys, or lack thereof.
>> Each distinct identity SHOULD be modelled separately; a direct or derived link to one identity makes no statement any other identities found in the Identity Equivalence Set.
> 
> I must say that it is difficult for me to capture what the whole text you are quoting is saying in every detail. I might have to devote more time to it (and acquire some basics of graph theory ;-) ), but possibly I will not be the only reader with this problem. Is it possible to give a direct example for the email case for each statement of this text?

If I give the impression that graph theory expertise is required, then I have definitely worded it wrong! ;-)

I had to distinguish between direct and derived identity links to avoid recursive definitions. A direct link is one that would exist anyway without the equivalence binding, and a derived link is one that relies on equivalence. You may have multiple direct identity links, for example if you had a certification pathway to the matching user IDs in both the deprecated and replacement certificates.

Let’s say Alice has two deprecated keys (one RSA and one ECC, for convenience), and a replacement key (ML-DSA). Let’s also say that she has the identity [email protected] <mailto:[email protected]> on the RSA and ML-DSA keys, and the identity [email protected] <mailto:[email protected]> on the ECC and RSA keys.

If Bob has made a certification signature over [email protected] <mailto:[email protected]> and the RSA key, then from his point of view there is a direct identity link between [email protected] <mailto:[email protected]> and her RSA key, and a derived identity link (via equivalence) between it and both of the other two keys. These derived links are subsidiary to the direct link and do not have an independent existence - if Bob’s certification expires, the direct link is invalidated and by extension the derived links are also invalidated. If however Bob also made a certification signature over Alice’s ML-DSA key, then the expiration of the first certification would not invalidate the second, and all three keys would remain linked to [email protected] <mailto:[email protected]> - but now Bob’s certification over the ML-DSA key would anchor the direct identity link, and the link between [email protected] <mailto:[email protected]> and her RSA key would now be equivalence-derived.

None of the above has any consequence for the identity [email protected] <mailto:[email protected]> - Bob knows of no proof that Alice owns that email address, and while her ECC certificate may claim [email protected] <mailto:[email protected]>, and we may therefore infer that the owner of the other certificates also claims [email protected] <mailto:[email protected]> (because equivalence implies they are the same person), there is no proof of anything. But let’s say that Bob then receives an email from [email protected] <mailto:[email protected]> with the ECC certificate in its Autocrypt header. He MAY therefore infer that the identity [email protected] <mailto:[email protected]> is directly linked (via the TOFU principle) to the ECC certificate - and thereby also to the other two certificates. This TOFU-based direct identity link may be considered “weaker” than one based on a certification signature, and so the derived identity links on the other two certificates SHOULD be considered equally “weak". If Bob subsequently certifies the identity [email protected] <mailto:[email protected]> on the RSA key, all the derived links would become subsidiary to that link, and also become equally “strong”.

A

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 833 B)