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

Andrew Gallagher <[email protected]> Fri, 8 Aug 2025 00:30:52 +0100
Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>
On 7 Aug 2025, at 08:35, Falko Strenzke <[email protected]> wrote:
> I think it would make sense that this draft explicitly defines what key equivalence technically means. To use the word "trust" in that explanation might make sense, then it needs to be defined as well of course.
> In my understanding, there are two flavours of trust that can be seen as relevant here:
> 
> A) Direct Entity Trust. This means that I trust the keys in a certificate to be owned by a certain entity.
> 
> B) User-ID Trust. This means that I trust the certificate to identify the correct user ID as associated with the key. In other words, even if I don't know the entity, I trust that the same entity controls the the service(s) (e.g., email) associated with the user ID and the key in the certificate. I think that for the draft it is not necessary to actually distinguish these two for the purpose of key equivalence, but it might make sense to mention them both – if they both apply.
> 

Traditionally in OpenPGP, “trust” has had two broad meanings. The first is “ownertrust”, the idea that the key’s owner is suitably honest to act as a “trusted introducer” or “certificate authority”. The second is “key trust”, which is the value calculated and emitted by a “trust algorithm” and which determines whether an implementation will consider a particular key "usable" in a given scenario (e.g. “please encrypt an email to Falko”). I think your flavours map roughly onto these, although flavour B reads to me like “I believe this key makes accurate claims about its User IDs”, while “key trust” is closer to “I believe this key makes an accurate claim about *this* User ID”.

My first issue with the “trust" terminology is that “ownertrust” is an input to the trust algorithm, while “key trust” is an output, and using “trust” for both inputs and outputs obfuscates what a trust algorithm actually does. But my more fundamental issue is that “trust” is something that only people are capable of, and anything that is the output of an algorithm must not be called “trust”, because it does not represent the user’s opinion, but rather the computer’s.

> That naturally raises the question in how far User IDs matter in the "key equivalence group" (a term I suggest that could be used in the draft also). If neither certificate carries User ID packets, trust transference should clearly be possible (case A). But if both carry user ID packets with a) partial overlap or b) no overlap at all, is trust transference also possible? At least for what I mention under "B) User-ID Trust" above, the case b) seems a bit confusing.
> 

I think we can describe Key Equivalence Groups without referring specifically to User ID packets, but rather to the underlying concept that such packets represent - an identity “claim”. Such a claim can be explicit (there’s a User ID with a self-signature over it), or implicit (I found this in an Autocrypt header). We don’t need to get into such details in this draft, but I think it’s good to keep them in mind when drawing up suitably generic language.

> It seems to me that at the minimum, the draft would benefit from some clarifications what types of trust are supposed to be captured by the trust transference through key equivalance and if / how this relates to the contents of the User-ID packets of the certificates in the equivalence group.
> 

I agree, and have been thinking along the following lines:

* “trust” should be reserved for “ownertrust” and is therefore out of scope of this document

* The input to the Key Equivalence calculation is whether a particular identity claim regarding a key/certificate is considered authentic, or valid, by the receiving implementation. Whether the claim is explicit or implicit, and whether the claim validity derives from the web of trust, or provenance, or the user Just Said So, should not matter for the purposes of this draft.

* The output of the Key Equivalence calculation is that any valid identity claim (as determined by the previous bullet point) regarding one member of a Key Equivalence Set is automatically valid for all other (current) members of the Key Equivalence Set.

I think this would avoid the “trust” minefield entirely. And perhaps we should therefore talk about “Identity Equivalence” instead of “Key Equivalence”?

A

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