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

Hi Andrew,

Am 12.08.25 um 11:26 schrieb Andrew Gallagher:
> Hi, Falko.
>
> On 12 Aug 2025, at 09:19, Falko Strenzke<[email protected]> wrote:
>>>> Equivalence doesn’t mean that all userids are valid, it means that they are *as* valid for one primary key as they are for any other in the equivalence set. [email protected] is claimed by one cert but not verified, then a receiving implementation will treat it as claimed but not verified by the other cert of the set.
>>>>
>>>> Put another way, Alice does not “trust eve’s key” - she trusts a particular userid claimed by eve’s key.
>>>>
>>>> Does that help?
>>> Yeah, of course it makes sense to model trust on a per-user-ID basis. In my view that is something that could be mentioned in the document in at least one sentence (even though it might be obvious to a sensible implementer).
> I’ve used the following language in the editor’s copy, let me know if this is sufficiently unambiguous?
>
> —
>
> * An "identity" is any unique identifier such as an email address or "real name"; it is not limited to User IDs, for example it may be a record in a local database.
> * An "identity claim" is any statement, explicit or implied, that an identity belongs to a particular primary key; it does not need to be a certification signature and is not necessarily true.
> * An "identity link" is an identity claim that is considered to be true and accurate by the receiving implementation.
> * A "Identity Equivalence Binding" is a doubly-linked, directed relationship between two primary keys, one of which is the stated replacement for the other.
> * A "Identity Equivalence Set" is a collection of two or more primary keys whose Identity Equivalence Bindings form a maximal connected graph.
>
> …
>
> The existence of a matching pair of forward- and backward-reference Replacement Key subpackets on the most recent direct self-signatures or key revocations over two primary keys, with each referring to the other primary key, forms an Identity Equivalence Binding.
> A collection of certificates whose Identity Equivalence Bindings form a maximal connected graph (see {{graph-topology}}) is an Identity Equivalence Set, and all members of that set are said to be Identity Equivalent to each other.
>
> 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. 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.

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

Best regards,
Falko

>
> --
> A
>
-- 

*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]