[openpgp] Re: Another review of draft-ietf-openpgp-replaceme ntkey-04

Andrew Gallagher <[email protected]> Thu, 7 Aug 2025 12:31:39 +0100
Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>
Hi, Aron. Thanks very much for the review.

> On 3 Aug 2025, at 18:55, Aron Wussler <[email protected]> wrote:
> 
> 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.

Thanks, I’ve applied most of this, and also pasted in the TPK==Certificate boilerplate as seen in several other drafts.

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

Hm, yes this is a bit crufty - it used to be a statement about the (now removed) “no replacement” flag and so directly described the format of the Replacement Key subpacket. It now describes the semantics of a different subpacket.

However, after looking at it again I also think section 5.1.1 (Reasons for Revocation) is misplaced, since most of it has general application and is not specific to Key Equivalence. I will restructure.

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

In the original draft, bit 0x80 (only) was specified as a “no replacement” bit, so 0x40 was chosen as the next available bit. “No replacement" was obsoleted in draft-ietf-02 after noting that it duplicated the semantics of the “reason for revocation” subpacket, but “inverse” was left where it was for avoidance of confusion.

For consistency with other flag bit allocations, we could potentially move it to 0x01 instead?

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

These specify the form of a valid subpacket, so I think they are correct here. The topology emerges when combined with the restriction to one subpacket per signature, which comes later.

Agreed on the need for consequences though. How about:

“If a subpacket contains an unexpected number of target records, it is malformed and MUST be ignored.”

I think we also need to update the one-subpacket rule to account for malformed subpackets:

"If a signature contains more than one such subpacket, *even if malformed*, a receiving implementation MUST disregard them all."

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

Agreed.

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

Good catch, thanks!

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

Thanks, yes this is better.

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

-> “Absence of a 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?).

I’m not sure that normative language would be appropriate, since this note does not describe application behaviour but user behaviour. We could instead use normative language to say that a client MAY or SHOULD prompt the user to take action? What the user does thereafter is out of our control… ;-)

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

As dkg pointed out, this sentence MAY be unnecessary ;-) But I’ll keep this alternative wording in hand...

> 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

Yes, this section is repetitive. Thanks.

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

This is mostly a restatement of 5.2, but there it is MUST NOT instead. I’ll clean this up.

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

I’m coming around to this position myself. See also my reply to dkg…

Thanks again!
A

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