[openpgp] Re: Review of draft-ietf-openpgp-replacementkey-04
Andrew Gallagher <[email protected]>
| Newsgroups | gmane.ietf.openpgp |
|---|---|
| Message-ID | <[email protected]> |
Hi, Falko. Thanks very much for the review. On 29 Jul 2025, at 13:54, Falko Strenzke <[email protected]> wrote: > Editorial Remarks > > Introduce the abbreviation “TPK” properly. Since “TPK" is only used once, I’ll remove it instead. > https://www.ietf.org/archive/id/draft-ietf-openpgp-replacementkey-04.html#name-the-replacement-key-subpack > > First sentence of the section: reference to section by “from there” requires to move the reference out of the brackets. > Quote: “The absence of a Replacement Key subpacket SHOULD NOT be interpreted as meaning that there is no replacement (or original) for the current primary key.” → Move “or original” out of the brackets. It is not a clarification, but addresses a different case. Agreed. > https://www.ietf.org/archive/id/draft-ietf-openpgp-replacementkey-04.html#name-trust-and-validation-of-the > > It would be nice if this section also had an introductionary sentence before the first subsection. I’ll have a look here and see what I can do. > https://www.ietf.org/archive/id/draft-ietf-openpgp-replacementkey-04.html#name-key-equivalence-binding > > A formality: This section should also explicitly introduce the concept of “key equivalence”. So far it does only explicitly introduces only “key equivalence binding”. Later, in Section 6, the term “key equivalence” is used once. So it makes sense to modify an existing sentence or add one explaining the concept under this name. I conjecture that it will most likely be the same as “key equivalence binding”. The other option is of course to replace the occurrence of “key equivalence” without the word “binding”. dkg has mentioned this also, although he suggests putting it in the “Terminology” section, which I think may be a better place for it. I think of Key Equivalence (as a concept) and Key Equivalence Binding (as an implementation of that concept) as distinct ideas, and agree that it would be good to explicitly define the former in terms of the latter. > Quote: “If one primary key is validated for use in a particular context, then any primary key that has a Key Equivalence Binding with it (together with any bound subkeys) is also valid,” > Is “valid” the correct term here? I think the equivalence binding is addressing trust transference. Validity of a key seems to cover a broader range of aspects. The security considerations section also uses the term “trust”, which is in my view correct. Both “trust” and “valid” are ambiguous terms in OpenPGP. ;-) I’m not generally a fan of “trust”, although for Web of Trust related terms I think there’s no reasonable alternative terminology. See also my reply to dkg... > Quote: “b) contains a Replacement Key subpacket that does not refer to the other key.” -> append to the sentence " … to the other key in the same direction as did the previous Replacement Key Subpacket” Good catch! But I think we also need to consider the case where both certificates simultaneously invert the direction of the binding (say, because the keyholder changed their mind about which one should be preferred), in which case the equivalence binding should survive. I’ll add another clause to this condition. Thanks again! A _______________________________________________ openpgp mailing list -- [email protected] To unsubscribe send an email to [email protected]
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEKR55odxVrielLu+DXB7EBNWQZikFAmiT6W4ACgkQXB7EBNWQ Zin47RAAg3JWZPBWlXYyD1qsMkxbSNkQDlg3WSyeRgW7XneF8ZkDBYeySWqpEnET TttxmpNzpkazYSboxUt17mCtWEnTbS7hY1V4Ws4vWV4Pwe2EBbCytXf3kMnx+CsD Q+PxsAudL4g2ke/OtvsD0NJ9YL8EDtofJmmjM7iS7nppL2d2mkRoi4k97lq4XfFL Ufyu3G8p46QGkKd91iEF5ojZ9duia3DHEJZKshVXYrF2IdO47gaPQKHweQmvYYOA KW2d9Gtwec5mdW0fgUkmOhvru20ACgfLpW0uBdCGGPxBPVSSAaM5dZwrN4N44OhS kFnrNcIn5R8RkG6CII8BNdAXCNeW1CUqIOwuiqXh9N8EdXgnI/qYh2QV+cPG4CFf zLBsawG9UrOieatNYTxP1VXSEWmyl+tG0RQk8NOTwRF3Zs8wG/pw/sWwxeu68Un4 syQE76Z6E6KTgqe7weEa/Vd/4c3a/G68/+TqmSbc9ZcRfxosbBC3ZiXRdsVxuOQj bN992HRGn/67DNIzUPieNmyfyph08BF0+m34SxScckpWcBSEV1eEmFzKOfQBkyHB y6gtnSzPY1+ecBTZlnZxDEoRYlMk4qQ0Faq3mAmBw5jMideCLPrLw5NcNsyZGSho g9+a90IfxjDTlsAbd2j/C3jvT6H99oovbqNRkLQFqRhfB6XS48Q= =zP3E -----END PGP SIGNATURE-----