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

Andrew Gallagher <[email protected]> Sat, 16 Aug 2025 12:00:38 +0100
Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>
Hi, Falko.

On 13 Aug 2025, at 06:59, Falko Strenzke <[email protected]> wrote:
> Am 12.08.25 um 13:19 schrieb Andrew Gallagher:
>> Hi, Falko.
>> 
>> On 12 Aug 2025, at 11:15, Falko Strenzke <[email protected]> wrote:
>> 
>>> 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.

Will do.

>> 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 talks about numerous details how to handle User ID Packets, but doesn't mention that they may omit certain valid identities.

You’re right, this isn’t specified anywhere - but it has been commonly implemented for a long time. Consider GnuPG’s group lines and Sequoia’s local bindings, which both allow a correspondent to (locally) associate any identity with any certificate, regardless of the UserIDs in that certificate.

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

Yes, this is a limitation. But I’m not sure the general case can be implemented without significant extra complexity. Not just complexity on the wire, but also complexity in the UX…

I’ve added the following caveat to the text:

“”"
An implementation SHOULD warn the user if they try to create an Identity Equivalence Group using certificates with mismatched current User IDs.
It SHOULD similarly warn the user if they try to add a new User ID to only one member of an Identity Equivalence Group, and (if possible) offer to add it to all members instead.
“””

This should be sufficient to warn key owners away from creating potentially ambiguous relationships.

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

Will do.

Thanks,
A

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