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

Andrew Gallagher <[email protected]> Thu, 7 Aug 2025 00:46:55 +0100
Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>
Hi, Daniel. Thanks very much for the review.

> On 4 Aug 2025, at 17:11, Daniel Kahn Gillmor <[email protected]> wrote:
> 
> Rather than "Replacement primary key", how
> about "preferred primary key".  and instead of "original primary key",
> how about "deprecated primary key"?

This feels like an improvement to me. Would anyone have an objection?

> It might be nice to have a diagram or two visualizing what can
> be represented in this model.  I find using aasvg works pretty well in
> the IETF document publication process for producing decent looking
> diagrams that translate well enough to txt, html, and pdf output
> formats.

Opened an issue for this (#33).

> I recommend choosing one of the experimental packet type IDs and using
> it as a placeholder for the TBD codepoint in this document.  That will
> help the different implementations do interoperability testing.

I suppose the time has come! ;-)

Any objections to using subpacket code point 100? Is anyone else using it currently?

> "All undefined flags MUST be zero" -  think this refers to subpacket
> generation.  It should explicitly say something like "When producing…",
> since the next sentence talks about "encountering".

Agreed.

> I don't like the term "Inverse Relationship" for the 0x40 bit.  Inverse
> implies that one thing is the "normal" way, but it's not obvious from
> looking at it which way should be which.  If we go with "preferred" and
> "deprecated" to describe the keys in the grouping, and this bit being
> set indicates that the current key is preferred, let's just call it
> "preferred" or something.

Hm, but does “preferred" mean that *this* certificate is preferred, or the one(s) being referenced? I think “forward” and “inverse” are clearer, because they indicate a property of the relationship, not a property of either end. And a “normal” reference is surely one that directs the reader from old to new, deprecated to preferred? I am open to alternative suggestions though.

> Why is the subfield "Record Length" field two octets?  a v6 fingerprint
> is 32 octets long, and the imprint is the length of the signature's
> digest.  The longest OpenPGP digest algorithms (SHA512 and SHA3-512) are
> 64 octets long.  Even if we have some new key version with a 512-bit (64
> octet) fingerprint, *and* the largest possible sig digest, we're still
> only at 1+64+64=129 octets for the field.  The first octet will always
> be zero.  why not make it one octet?

I’ll admit this is a cautious design decsion. Yes, as far as we can tell now it seems unlikely that a digest algorithm of more than 512 bits will be necessary in the foreseeable future. But if it were, we could conceivably exceed the capacity of a single octet. Given the overall size of the target record, one spare octet is not that significant.

> Additionally, if 0x40 is unset, we could also omit the record length all
> together, since the remainder of the packet is the record.  Any
> additional material in the subpacket beyond the single record will
> violate the MUST in
> https://www.ietf.org/archive/id/draft-ietf-openpgp-replacementkey-04.html#section-4-11.1.1

It’s true that the record length is sometimes redundant, but I specified it for all cases to simplify the parsing logic. If implementers think this is not necessary, and the redundant record length should be removed, I’ll go along.

> The term "trust" is both overused and underspecified in OpenPGP.  Can we
> replace it here eto make it say what we mean specifically?  here are
> some ambiguous/unclear statements:
> 
> - calculating partial trust values
> - trust pathways
> - trust statement
> - infer any trust value
> 
> I think we can leave the term "Web of Trust" in the text, but maybe use
> it with a reference to some document that describes it?
> https://sequoia-pgp.gitlab.io/sequoia-wot/ is one example (though it
> hasn't been submitted to the datatracker as far as i'm aware).

I think most (all?) of these are established Web of Trust terms? It would be nice if there was a more official document to reference though ;-)

> if A deprecates B and C, and B and C both indicate that they prefer A,
> then we have a 3-part key equivalence.  But if B is (for example)
> hard-revoked, then the what happens to the relationship between A and C?
> A's Replacement Key subpacket still lists both B and C, right?  Should
> we be explicit that the evaluation between A and C is independent of the
> relationship between A and B?

I think this interpretation is the obvious one, but there’s no harm making it explicit. I will add.

> The definition of "hard" and "soft" revocations is ambiguous about most
> possible revocation reason codepoints, only marking a few as "hard" and
> a few as "soft".  The rest are unspecified.
> draft-dkg-openpgp-revocation is much more uniform view, where only two
> are soft, and the rest are hard.  I don't see how the ambiguity helps
> anything.  Why not just mark them all as hard except for "Key is
> superseded" and "Key is retired and no longer used"?
> 
> If you want to just adopt the entire description from the revocation
> draft (and the IANA considerations too) i wouldn't object.

I’m not entirely convinced that unknown reasons should automatically be hard. Hockeypuck deletes userids from hard-revoked keys but not soft-revoked ones, because soft-revoked keys are still useful for historical purposes and deleting userids would render them unusable. An assumption that all unknown reasons are hard would make it difficult to roll out a new soft revocation reason without data loss. Maybe we need three classes of revocation?

> The draft makes a strange carveout for the encrypt-to-self scenario.  It
> says:
> 
>> When encrypting to herself, the key owner is not required to use the
>> same encryption subkey selection algorithm as her correspondents.
> 
> But the other guidance is all SHOULD, right?  why do we need this? I see
> that it was added in b321b95266ec5db6959ca040fe60e0168d62b557, along
> with the example note about using persistent symmetric keys.

As I recall, this was added to explicitly avoid a clash of recommendations between this draft and the symmetric key draft. However, we could agree to defer such discussion to the symmetric key draft, since we can’t yet use it as a normative reference anyway…?

> The section about Placement of the Replacement Key Subpacket uses MUSTs
> (which i think are warranted) but it seems like it is implicitly written
> from the emitter's point of view.  It would be useful to write the
> guidance specifically from the receiver's perspective.  If it encounters
> this subpacket in an inappropriate place, what should it do?
> 
> Then the emitter's MUSTs will be clearly motivated.

I would say that a receiving implementation MUST ignore a misplaced subpacket. Is it still meaningful for the producer’s guidance to be MUST NOT in this case?

> The Security Considerations section describes the imprint as "a digest
> over the target primary public key packet".  But earlier the draft says
> "It is calculated in the same way as the fingerprint".  The fingerprint
> is subtly different than just a digest over the public key packet,
> though, right?  Maybe the Security Considerations should say "a digest
> over the material in the target primary key packet" or something?

Agreed.

> v3 keys are already deprecated.  Do we want to explicitly preclude the
> use of this mechanism for v3 keys?  Or, if we want people to be able to
> use this mechanism to move from a v3 key to a more modern key, do we
> want to adjust the imprint mechanism for v3 keys as a special case?

v3 self-signatures don’t have subpackets, so this mechanism cannot be used to specify a replacement for a v3 primary key. It would be possible (if perverse) to unilaterally specify a v3 primary key as a replacement for a v4 one, but it would not be possible to complete an equivalence binding. Do we need to call this out specifically?

> # Example Workflows
> 
> I really like the thought that has clearly gone into these workflows.
> 
> I worry, though, that the presentation is intimidatingly complex and
> might be challenging to reason about.
> 
> I think it might be easier to stage the workflows into clear examples
> with explicit contexts, starting simple, and moving toward more complex.
> 
> The context might describe the number of devices that share a secret
> key, whether synchronization channels exist, and the keyholder's
> preferred mechanism for certificate distribution to their peers.
> 
> So the first example might be: Alice has a single device; she publishes
> her keys on public keyservers; and she wants to transition to a new key
> but suspects some of her peers will not be able to support the new key
> format or algorithm yet.
> 
> The second example, John has two devices that already share a secret
> key, along with a synchronization channel, and he wants to upgrade
> smoothly.  He distributes his certificates to his peers in-band (e.g. in
> an Autocrypt header in e-mails).  And so on...
> 
> If you describe each example scenario clearly, then it should be clear
> which example guidance should be relevant for a given scenario.  In the
> current text, there is one "example" but it tries to cover all sorts of
> cases, which makes it more complex than it needs to be.

I’ll come back to this once I’ve dealt with the more specific points. ;-)

Thanks again!
A

(P.S. I haven’t forgotten about you, Aron - it’s just getting late...)

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