[openpgp] Matters arising from IETF-121 re draft-replacementkey

[Andrew Gallagher <[e-mail]>]

On 19 Nov 2024, at 18:05, Stephen Farrell <[e-mail]> wrote:
> 
> [1] https://datatracker.ietf.org/doc/minutes-121-openpgp-202411070930/

Thanks, Stephen!

There are some outstanding items for draft-replacementkey arising from the minutes. I’ll summarise them below:

1. It was decided to remove the reference to the Preferred Keyserver subpacket - this will be removed from the next draft unless anyone objects before Friday. [1]

2. It was also indicated that there was no consensus in favour of changing the format of the Target Record, which is currently:

    ( Record Length || Target Key Version || Target Key Fingerprint || Target Key Imprint )

Unless there is a rough consensus otherwise on the list, this will stay as is.

3. The name of the draft (and potentially the subpacket). Several people have indicated that they wish to change it to “Certificate Replacement”. I’m personally not in favour of this because I think it is imprecise — it is already possible to “replace" a certificate with a modified one that shares the same primary key, while this mechanism is only useful for certificate replacement that also includes primary key replacement.

As a counter-proposal, I would suggest “Primary Key Replacement”, which I believe describes more precisely what exactly is achieved by the mechanism. I know Justus doesn’t like it, but I’d like to hear some other opinions, either way. :-)

4. There is also one other item which we mentioned at the interim but is not in the minutes, which is whether to include an “encrypt to all equivalent keys” mechanism. I am reluctant to do this as it is a significant expansion of scope. As a counter-proposal, we could instead invert the meaning of the following text in the draft:

> An implementation that encounters a class octet that has other bits set MUST disregard that Replacement Key subpacket.

This text is included so that we can make breaking changes to the packet format in the future while preventing misinterpretation by legacy software. This would however prevent us from adding an optional flag in the future that indicated encryption preference - this would be a non-breaking change where the new flag SHOULD be ignored, rather than invalidating the subpacket (which the current text states).

Inverting this text would allow us to specify such a mechanism in a later draft, at the cost of requiring us to use a new subpacket type if we were ever to make a breaking change to the wire format. [2]

So would the counter-proposal be acceptable? If so, we should be able to finalise the wire format of the draft this week.

Comments welcome!

Thanks,
Andrew.

[1] https://gitlab.com/andrewgdotcom/openpgp-replacementkey/-/merge_requests/15/diffs
[2] https://gitlab.com/andrewgdotcom/openpgp-replacementkey/-/issues/14#note_2218974758