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

[Andrew Gallagher <[e-mail]>]

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