[openpgp] Re: I-D Action: draft-ietf-openpgp-replacementkey-01.txt

[Andrew Gallagher <[e-mail]>]

Hi, everyone.

I have updated the replacement key draft based on feedback received at (and subsequent to) the interim meeting [0]. The main changes are:

* Updated references to RFC9580
* Removed subpacket version field
* Added record-length fields (for robust parsing of unknown fingerprint versions)
* Added explicit guidance for encryption subkey selection
* Renamed to “OpenPGP Key Replacement” for brevity
* Further disambiguation of “key” in the text, using “primary key” or “certificate (TPK)” as appropriate

The most urgent open question is the target record format. Specifically, whether we want the imprint (or fingerprint) field of a target record to be optional (truncation of the record), and under what circumstances it may take place. The addition of the record-length field allows truncation to be directly detected, so we could defer a truncation policy to some later date without further wire format changes.

As I see it, there are three broad options (in order of preference) [1]:

1. Both fingerprint and imprint are required (no change)
2. Imprint is optional, either:
	a. iff it is the same as the fingerprint
	b. at the key owner’s discretion
3. Fingerprint is optional, either:
	a. iff it is the same as the imprint
	b. at the key owner’s discretion

The “opportunistic truncation” options 2a and 3a are effectively the same, just with the fields reordered on the wire. They complicate the parser in exchange for saving some bytes on the wire, but otherwise have the same functional and security properties as option 1.

If we choose option 2b, we have to accept that (1) the imprint is not necessary for key equivalence, or (2) key equivalence is not always achieved even with matching forwards and reverse subpackets.

If we choose the “aggressive truncation" option 3b, or wish to keep it open for some later date, we need to reorder the fields so that the fingerprint comes at the end of the record, and we will have to accept that fingerprint search may no longer be possible, which is a significant breaking change in the ecosystem.

Other remaining open questions are:

* Do we need further UX guidance, and if so what should be included? [2]
* Is the current guidance on encryption key selection sufficient? [3]
* Is the terminology used in the draft clear and unambiguous?

Please discuss the above on the list, and I will raise any discussion outcomes at IETF121. Unfortunately I won’t be able to be present in person as I had previously hoped.

To the chairs: please allocate a slot for discussion of this draft.

Thanks,
A

[0] https://datatracker.ietf.org/doc/minutes-interim-2024-openpgp-03-202409091100/
[1] https://gitlab.com/andrewgdotcom/openpgp-replacementkey/-/issues/15#note_2170090925
[2] https://gitlab.com/andrewgdotcom/openpgp-replacementkey/-/issues/17
[3] https://gitlab.com/andrewgdotcom/openpgp-replacementkey/-/issues/14

> On 21 Oct 2024, at 22:27, [e-mail] wrote:
> 
> Internet-Draft draft-ietf-openpgp-replacementkey-01.txt is now available. It
> is a work item of the Open Specification for Pretty Good Privacy (OPENPGP) WG
> of the IETF.
> 
>   Title:   OpenPGP Key Replacement
>   Authors: Daphne Shaw
>            Andrew Gallagher
>   Name:    draft-ietf-openpgp-replacementkey-01.txt
>   Pages:   13
>   Dates:   2024-10-21
> 
> Abstract:
> 
>   This document specifies a method in OpenPGP to suggest a replacement
>   for an expired, revoked, or deprecated primary key.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-openpgp-replacementkey/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-replacementkey-01
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-openpgp-replacementkey-01
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> _______________________________________________
> openpgp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]