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

On Tue 2025-07-29 14:54:15 +0200, Falko Strenzke wrote:
> I made a review of draft-ietf-openpgp-replacementkey-04 

Thanks for this review, Falko!

With no hats on, I've just read through the same document as well.  I
like it, and think it does a good job describing its goals (which i
think are reasonable goals), and meeting them.

I have the following comments for improvement.  I'm willing to make MRs
for them if that would be helpful.

# Clearer Terminology

The terminology section introduces "replacement primary key" and
"original primary key" without explaining what "replacement" and
"original" mean.  I also find the way that the draft uses the terms
"replacement" and "original" somewhat confusing.  I tend to think of the
"original" as being a singular thing, but many things can replace it.
However, the draft shows that there can be multiple "original"s and only
one "replacement".

Given that the subpacket is named "Replacement Key", and it sometimes
contains a "replacement primary key" and other times contains an
"original primary key", it all seems a bit more confusing than we might
want.

I agree with Falko that "Key Equivalence" as a concept needs to be
defined up front as well, since that concept makes the rest of the draft
easier to understand.

I recommend picking explicit and distinct terms and describing them
in the terminology section.  Rather than "Replacement primary key", how
about "preferred primary key".  and instead of "original primary key",
how about "deprecated primary key"?

Then you can define a "key equivalence" set as consisting of a single
"preferred primary key" and 1 or more "deprecated primary keys".

Likewise, the text refers to "original certificate" and "replacement
certificate", but they aren't defined in the terminology section.

In other documents i've worked on and reviewed, the Terminology section
is used to give a very short (one sentence) gloss for a term, while also
referring to another section of the document for more details.

# Visualization

In the discussion at the OpenPGP e-mail summit, i think it helped a lot
to have some drawings of the conceptual arrangement we were talking
about.  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. 

# Subpacket type ID

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.

# Undefined Flag Bits

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

# "Inverse Relationship"

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.

# Record Length is too big

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?

It looks like the goal here is to provide some sort of future
extensibility, to allow some new specification to stuff additional data
about the relationship between the keys in the Equivalence.  But why?
Extra flexibility is the bane of interoperability.

# No Record Length needed on Preferred subpacket 

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

# "Trust"

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

# Key Equivalence

A Key Equivalence group is not limited to two keys, because the
preferred key can note that it has multiple deprecated keys.  But the
"Key Equivalence Binding" section describes pairwise equivalence.  In
some cases, one pairwise part of an equivalence binding might be
invalidated.  For example:

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?

# Soft vs. Hard revocation reasons

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.

# encrypt-to-self carveout seems unnecessary

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.  This seems
like an excessive statement.  no one is "required" to do anything else,
all the statements about which keys to use are SHOULDs anyway, and
surely local guidance (or guidance in the persistent symmetric keys
draft) can override those SHOULDs.

I think the draft would be simpler without this line (though if you want
to leave the aside in the example workflow, that seems reasonable to
me).

# Placement

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.

# Imprint description

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?

# v3 Imprints

Assuming that an imprint is calculated over the same bytestream as the
corresponding fingerprint, that raises a concern for v3
imprints. fingerprints are bad not only because they use MD5; they are
bad because they don't include a delimiter between the RSA modulus and
exponent in the input bytestream.  This suggests that the imprint of a
v3 key is similarly weak.

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?

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

Hope this is a useful review!  Again, i'd be happy to make issues or
merge requests out of many of these remarks that you want to tackle, if
that workflow would be helpful to the editors.

Regards,

        --dkg

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