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

[Daniel Huigens <[e-mail]>]

Hi Andrew,

The reasoning makes sense to me, so I'd agree with dropping the "no
replacement" bit. Indeed I also don't particularly see a use case for
explicitly stating the default.

---

To throw another (hopefully not-too-big) spanner: I have previously
argued in defense of the name "replacement key" (as opposed to e.g.
"replacement certificate"), mostly because in my mind the draft
described the process of a key holder replacing their (private) key
as much as replacing the public key/certificate.

_However_, if we add persistent symmetric keys to the mix, this might
not be true anymore. E.g.: the key holder could switch from a v4 ECC
key to a v6 PQC key _plus_ a v6 symmetric key, but their correspondents
only see them switching from a v4 ECC certificate to a v6 PQC
certificate, and this draft will only describe that part.

Concretely, this means that the draft also can't be used to decide
which _key_ to use (when signing or encrypting for private storage,
for example), only which _certificate_ to use (e.g. for communication).
(Perhaps the draft should spell that out explicitly?)

And so, though I have my own mild reservations about the term
"certificate" for TPKs, it's clear enough, and given the above, I
find myself agreeing more with Justus's point that perhaps the draft
and subpacket should be renamed to "replacement certificate".

Alternatively, we could change the scope of the draft slightly and also
include the scenario I described above, but nevertheless the _subpacket_
should probably still be named "replacement certificate" as there's no
real point including a replacement persistent symmetric key in it.

Best,
Daniel


On Friday, November 15th, 2024 at 19:55, Andrew Gallagher wrote:

> Hi, all.
> 
> Justus reminded me[1] that there is no standard definition (yet!) of hard v soft revocations, so I’ve included some text in the latest gitlab copy to cover that omission. It currently reads:
> 
> —
> 
> * "hard-revoked" means the key has been revoked with a Reason for Revocation subpacket specifying "Key material has been compromised" or "No reason specified"; the absence of a Reason for Revocation subpacket is equivalent to "No reason specified”.
> 
> * "soft-revoked" means the key has been revoked with a Reason for Revocation subpacket specifying "Key is superseded" or "Key is retired and no longer used”.
> 
> If a Key Revocation signature contains a Replacement Key subpacket, a Reason for Revocation subpacket MUST also be included, to prevent it from being interpreted as "No reason specified", which is a hard revocation.
> 
> * if the Replacement Key subpacket has the "no replacement" bit set, the Reason for Revocation subpacket SHOULD indicate "Key is retired and no longer used”.
> 
> * if the Replacement Key subpacket does not have the "no replacement" bit set, the Reason For Revocation subpacket SHOULD indicate "Key is superseded”.
> 
> —
> 
> The requirement for an explicitly soft Reason for Revocation subpacket flows directly from the normal interpretation of hard revocations as meaning “no signatures made by this key are trustworthy, including this one”. A Replacement Key subpacket in a hard revocation signature is therefore non-functional, so we have to provide a soft Reason for Revocation subpacket, which is constrained to either “Key is superseded” or “Key is retired and no longer used”. However, this appears to duplicate the semantics of the 0x80 “no replacement” bit in the scenario where a key has been revoked.
> 
> The only context where the “no replacement” bit still appears to have distinct semantics is in the case where a) the current key is not revoked, b) there is no other preferred or fallback key, and c) the key owner wishes to make an explicit statement to that effect. But since a) plus b) represents the default scenario, it seems unnecessary to cater for such an explicit non-statement.
> 
> So I’m going to throw a last-minute spanner in the works and ask: do we still need the “no replacement” bit? I know that Daphne and I both previously argued that we do, but the particular scenario that I had in mind was being able to differentiate between “revoked, no replacement” and “revoked, replacement unspecified” which seems to be already covered by Reason for Revocation values, and is in any case not meaningful to an automated process.
> 
> A
> 
> [1] https://gitlab.com/andrewgdotcom/openpgp-replacementkey/-/issues/25
> 
> _______________________________________________
> openpgp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]