[openpgp] Another review of draft-ietf-openpgp-replacementkey- 04

Hello everyone, 

Here's my review of draft-ietf-openpgp-replacementkey-04, as promised at IETF 123.

Like Falko, I think that it's quite ready, and support its deployment. Here are some mostly editorial changes to the draft I would still like to propose.

Section 2.1: The text is quite hard to parse. I gave it a try and rephrased it.

> In OpenPGP, the term "key" has often been used broadly to describe different concepts, which can lead to confusion. To avoid ambiguity in this document, we define the following terms:
> 

> -   "Replacement Primary Key" and "Original Primary Key": These refer to a primary key as found in a Transferable Public Key (TPK) (Section 10.1 of [RFC9580]) or a Transferable Secret Key (TSK) (Section 10.2 of [RFC9580]).
>     

> -   "Target Key": This term refers to either a replacement or original primary key that is specified in a Replacement Key subpacket.
>     

> -   "Current Primary Key": This is the primary key associated with the self-signature being discussed.
>     

> -   "Replacement Certificate", "Original Certificate", and "Current Certificate": These terms refer to the Transferable Public Key (TPK) that contains the respective primary key.
>     


Section 3: I don't like forward references, and here we have a normative reference, pointing to section 5.1.1, where the normative reference is partially repeated.
I would therefore remove the statement "To explicitly ... SHOULD be used (see Section 5.1.1)".

Section 4: Flag bit 0x40 - Why the 2nd bit out of all of them?

Section 4: the two statements

> If the class octet does not have the 0x40 bit set, the subpacket MUST contain exactly one target record to identify the replacement primary key.
> 

> If the class octet has the 0x40 bit set, the subpacket contains one or more target records, to identify the original primary key(s) that the current primary key is a replacement for.

Should IMO go in section 4.2, they refer to the topology. Also there should be a consequence for failing a MUST (e.g. otherwise, the whole subpacket is to be ignored)

Section 4: I would also rephrase the last sentence

> If the replacement (or original) primary key is unknown, a Replacement Key subpacket SHOULD NOT be included in the signature.


Section 4.1: We specify how to issue key imprints, but not that they should be validated. I would add at the end

> When an implementation has located a target key, it MUST verify that the imprint matches.


(Also side note, "except that it MAY use a digest algorithm": I believe this MAY should not be a normative MAY, but a plain "may" in an English sentence)

Section 5.1: I would rephrase "If either primary key is hard-revoked ... unaffected" to

> If either primary key is hard-revoked, then the equivalence binding is invalidated but the other key is not revoked.


Section 5.2: I would rename the section to "Absence of Key Equivalence Binding"

Section 5.2: "It is also suggested that the key owner asks"... We're getting into RFC 6919 land. I would propose to make it normative (MAY?).

Section 6: "When encrypting to herself..." to:

> When encrypting messages to themselves, key owners are MAY use the a different encryption subkey selection algorithm as the one used for their correspondents.


Section 7: This is a repetition of what is specified in section 3. But I like it more how it's written there. I would remove this whole section and move "If the Replacement Key subpacket ... to an existing signature." to a security consideration


Section 8: "In the absence of ..." AFAIK the security considerations should not be normative. I would move the normative sentence to section 5.2.

Appendix A.1: I don't know if mentioning the symmetric keys draft is a good idea, probably there it should be specified that this mechanism takes precedence over other (sub)key selection mechanisms.

Cheers,
Aron

--
Aron Wussler
Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930

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

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0FgmiPopkJkH5nYVY+/jkwRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmfPuNdBjEUzAGNPGbnxiB1sxC/HsyUrW1HNPy88
ibBHzxYhBIuVslFfa7tqthSdVX5nYVY+/jkwAABqOwD+PEnTTh0rmcCen0OM
uJpgiCmYSImpW8X2b4QlTGXIbMAA/1NYoKSf8hgVp8TTNjln0yA417Ll+tOc
VlKLstLgrWIB
=FQ5j
-----END PGP SIGNATURE-----