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

Hi Andrew,

Am 12.08.25 um 13:19 schrieb Andrew Gallagher:
> 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.
In that case I would say this fact about the email use case should be 
concretely pointed out in the document. That will help readers to 
understand this important use case as well as the general idea.
>
>> 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.

Thanks for the explanation. I now understand the idea. I personally 
would see it a bit different: when user IDs are contained in a 
certificate, one should conclude that those are the intended ones, and 
not any others. But I don't want to argue about this. If this is the WGs 
understanding of the user ID, then it needs to be explained by the 
Replacement Key Draft in my view. I wouldn't know where RFC 9580 
explains this. Section 10.1.5 
<https://www.rfc-editor.org/rfc/rfc9580.html#section-10.1.5> talks about 
numerous details how to handle User ID Packets, but doesn't mention that 
they may omit certain valid identities.

I guess all this means that it is not possible to discard a user ID when 
transitioning from the deprecated to the replacement certificate. Also 
introducing new user IDs in the replacement certificate may lead to 
other users starting to send messages encrypted to the that new ID using 
the deprecated key, which might not be available for that ID. To me that 
looks like potential for disturbance. But if that is really intended, so 
be it. Please just document all this. This can all be very brief, but it 
needs to be said.

>
>>> 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 [email protected] <mailto:[email protected]> on the RSA and ML-DSA keys, and the [email protected] <mailto:[email protected]> on the ECC and RSA keys.
>
> If Bob has made a certification signature [email protected] <mailto:[email protected]> and the RSA key, then from his point of view there is a direct identity link [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 [email protected] <mailto:[email protected]> - but now Bob’s certification over the ML-DSA key would anchor the direct identity link, and the link [email protected] <mailto:[email protected]> and her RSA key would now be equivalence-derived.
>
> None of the above has any consequence for the [email protected] <mailto:[email protected]> - Bob knows of no proof that Alice owns that email address, and while her ECC certificate may [email protected] <mailto:[email protected]>, and we may therefore infer that the owner of the other certificates also [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 [email protected] <mailto:[email protected]> with the ECC certificate in its Autocrypt header. He MAY therefore infer that the [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 [email protected] <mailto:[email protected]> on the RSA key, all the derived links would become subsidiary to that link, and also become equally “strong”.

Thanks, this is a really useful example. I suggest – in line with DKG's 
comments – that you add a figure to it and then add this to the examples 
section.

But again the point where I disagree is the assumption of a person that 
is controlling all the user IDs and keys. That seems too simple and in 
my view doesn't capture real situations where a user has different keys 
on different devices that are used for different email accounts. As I 
pointed out above, the extension of user ID claims via indirect links 
may easily lead to disruption when user IDs are added or removed between 
two certificates from the equivalence set.

Best regards,
Falko

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

*MTG AG*
Dr. Falko Strenzke

Phone: +49 6151 8000 24
E-Mail: [email protected]
Web: mtg.de <https://www.mtg.de>

------------------------------------------------------------------------

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If 
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised 
copying or distribution of this email is not permitted.

Data protection information: Privacy policy 
<https://www.mtg.de/en/privacy-policy>

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