[openpgp] Re: Some comments on draft-dkg-openpgp-revocation-02

[Andrew Gallagher <[e-mail]>]

Hi, Neal. Thanks for taking the time to review the document, much appreciated!

On 3 Apr 2025, at 13:52, Neal H. Walfield <[e-mail]> wrote:
> 
> RFC 9580 includes a signature target packet that allows revoking a
> particular signature:
>  https://www.rfc-editor.org/rfc/rfc9580.html#section-5.2.3.33

It’s not in the current editor’s copy, but in issue 13 I describe how the signature target packet does not reliably identify a single signature - admittedly it is an edge case, but one that an attacker could conceivably exploit. It’s not even clear how to construct one based purely on the RFC texts, although I argue in that ticket that there’s only one construction that is reasonably consistent with the description of its properties:

https://gitlab.com/dkg/openpgp-revocation/-/issues/13

>> 2.  What Can Be Revoked: Keys, Subkeys, Certifications?
>> 
>> A key may be temporarily invalidated by specifying an expiry date on
>> a new Direct Key, Subkey Binding, or Certification Signature.
> 
> At least in Sequoia, this wouldn't work.  When we consider the set of
> binding signatures for an object at time t, we ignore signatures that
> are expired at time t.  In other words, Sequoia ignores any expired
> signatures and selects an older one.
> 
>  https://gitlab.com/sequoia-pgp/sequoia/-/blob/b4f6ebc7/openpgp/src/cert/bundle.rs#L347

The expiry date on a binding signature would be a key expiry date, not a signature expiry date, so the signature itself would not expire. I will update the text to make this explicit. In draft-signatures, it is stated that “signature expiry” subpackets SHOULD NOT be used on direct key or binding signatures, to avoid unexpected semantics like this.

> Another way to temporarily invalidate an object is to issue a soft
> revocation and then later issue a new binding signature.  I think this
> is better and more flexible.  This approach is helpful if the expiry
> date is not known in advance.  It also doesn't require any further
> action if the expiry date turns out to be wrong, which I'd argue is
> safer.  Relatedly, this mechanism is the same one that is required
> when someone leaves an organisation and then later rejoins it.

I don’t see any advantage of this over issuing a new signature with an expiry date of “today”. We only need one mechanism for this, and it is already confusing enough for users to understand the concept of “un-expiry”, without also introducing the concept of “un-revocation”, which I think is even more counter-intuitive.

>> If the key owner does not have such a revocation stored safely,
>> there is nothing further that they can do cryptographically.
> 
> One idea that Justus and I have been thinking about is extending the
> idea of trusted introducers to trusted revokers.  One way this could
> be used is by a company whose CA revokes user IDs when an employee
> leaves the company.  I can also imagine a public service like k.o.o
> offering this type of service for email address-based user IDs.

I worry that any "trusted revokers” mechanism that relied on references to other certificates would have the same drawbacks as the old revocation key mechanism.

>> 2.3.  Revoking a Certification
>> 
>>   *  User ID No Longer Valid (0x32): "I believe that Bob no longer
>>      controls this identity"
> 
> I have a different interpretation: "I no longer believe that 0xB0B
> should be associated with this identity."

Agreed, I think this is improved phrasing. Thanks.

>> 3.1.  Obtaining Revocation Information
>> 
>>   When the keyholder changes to a new key, how do they distribute
>>   revocations for older keys?
> 
> I think you mean s/key/certificate/ .

Oops.

>> 3.2.  Revocations Using Weak Cryptography
>> 
>>   What if we find a Key Revocation signature made using SHA1 or MD5?
> 
> Sequoia's cryptograhic policy framework allows accepting a hash used
> to protect a revocation certificate longer than in other contexts.
> Our justification is that a forged revocation is a DoS, which is not
> as bad as a being tricked to accept a forged signature, because the
> revocation certificate was ignored.
> 
> See:
> 
>  https://docs.rs/sequoia-openpgp/latest/sequoia_openpgp/policy/struct.StandardPolicy.html#method.hash_revocation_tolerance

Do other implementations have a different policy?

>> 3.4.  Implications for Revoked Key Material
>> 
>>   If a primary key is revoked with Reason for Revocation 2 (key has
>>   been compromised), then an implementation MAY infer that any other
>>   certificate containing the same key material has also been
>>   compromised.
> 
> Let's say B binds A's primary key as a subkey.  If A's primary key is
> hard revoked, does that mean all of B should be considered revoked or
> only the subkey?

Revoking a subkey does not normally affect the primary it’s attached to, even in the case of key material compromise, so it would be very strange if a subkey that was revoked merely by inference had such an effect.

>> 3.5.  No Revocation Expiration
>> 
>>   While Revocation Signatures are signatures, the act of revocation is
>>   permanent
> 
> I disagree that revocation should be permanent.  If I have a user ID,
> <[e-mail]>, and I leave example.org, I should retire that user
> ID.  But if I later rejoin the org, I shouldn't have to create a new
> certificate to "unretire" <[e-mail]>.

What is the advantage of using revocations over a plain expiry in this use case? If there is no effective difference between a soft revocation and an expiry, then do we need both? But I’d argue that the ability to revoke something permanently is a feature, since it allows your correspondents to interpret the revocation as a tombstone.

Stepping back, it may be useful for us to more clearly distinguish between direct/binding signatures (and revocations thereof), self-certifications/revocations, and third-party certifications/revocations. They have quite distinct semantics, and maybe trying to impose the same behavour on all three is more confusing than helpful…?

>> 3.6.  Reasons for Revocation Mismatch
>> 
>>   How should an implementation interpret a Key Revocation signature or
>>   Subkey Revocation signature with Reason for Revocation subpacket with
>>   ID 32 ("User ID information is no longer valid")?
> 
> In Sequoia, we conservatively consider unknown reasons (in the given
> context) to be hard revocations.  Anything else means that it is much
> harder to introduce new reasons for revocation, as old implementations
> will ignore the revocation.  Although this may be slighly
> inconvenient, I think that it is safer than ignoring the revcation
> certificate.

I tend to agree that revocations should always be honored except in cases where it is likely that the revocation could have been forged (e.g. with weak algorithms).

> I think the creation time subpacket should be a MUST, as it is in
> RFC 9580.

Does MUST require that such a malformed revocation is ignored by a receiver? Is it not safer to honour a cryptographically-sound revocation signature even if it has unexpected subpackets? If a keyholder revokes their certificate and their implementation has a bug that means it omits to include the creation time, should we really reject the revocation? Or can we keep the MUST for producers while adding more lenient guidance for consumers?

>> 3.9.  What About Revocations From the Future?
>> 
>>   If a Revocation signature appears to have been made in the future,
>>   its interpretation will depend on whether it is hard or soft:
>> 
>>   *  If a hard revocation is from the future, then its creation date is
>>      irrelevant, since hard revocations are retrospective.  Hard
>>      revocations MUST be treated as if their creation date was in the
>>      infinite past, regardless of the value of the creation date
>>      subpacket.
> 
> I disagree.  If the signature (or the verification result) is stored
> on a trusted medium and the signature's creation time is prior to the
> hard revocation signature's creation time, which presumably reflects
> the time of compromise, it is reasonable to still consider the
> signature to be valid.

I don’t think it’s safe to presume that the revocation creation time reflects the time of compromise - it may only reflect the time that the compromise was discovered. If hard revocations are not retrospective, how do we invalidate a fraudulent signature that has already been published? A consumer of a “key compromised” revocation will not in general know when the key was compromised, and the key holder may not themselves know, so the scenario of “we know by other means that the signature creation has not been backdated and we know precisely the moment of key compromise, therefore this signature is still safe” seems to me a very edge case, and not worth the risk or complexity that it introduces.

>>   Since an encryption subkey is not useful for historical purposes,
>>   only for creating new encrypted data
> 
> Minor: I think old key material is still useful for decrypting
> old messages.

The key material is, but the public subkey packet is not required in general for the owner to decrypt, so long as there is some local reference from the fingerprint to the key material (the usual caveats re ECC curve parameters apply though). The wording here is not ideal, will fix.

>> 7.  Escrowed Revocation Certificate
>>   Since the reason for publishing an escrowed revocation cannot be
>>   known in advance, escrowed revocations SHOULD NOT include a Reason
>>   for Revocation subpacket.  If such a subpacket is included, it SHOULD
>>   explicitly state a reason of "none" (0x00).
>> 
>>   Since the reason for publishing an escrowed revocation cannot be
>>   known in advance, escrowed revocations SHOULD NOT include a Reason
>>   for Revocation subpacket.  If such a subpacket is included, it SHOULD
>>   explicitly state a reason of "none" (0x00).
> 
> I'm not so into this.  I plan to extend sq to not generate a single
> revocation certificate, but a bunch: one for each month of validity
> and one for each of "retired" and "key compromised".  In this way,
> when the user needs an escrowed revocation certificate, sq can choose
> the most accurate one.

As stated above, the creation date of a hard revocation is not meaningful from the consumer’s point of view, so any hard revocation is equivalent to any other. For the “retired” use case, maybe - but I worry that this is overkill for the majority of users and may encourage confusing UX.

> FWIW, I can only think of two situations that require this mechanism
> and both have to do with the user completely losing access to their
> key material: the device is stolen and the key is compromised, or the
> device is destroyed or the user forgot the password protecting the key
> material and the key is effectively retired.
> 
> I think in most cases where the key material is compromised, the user
> still has access to the key, and can issue a precise revocation
> certificate.  And because it is more precise, that should be preferred

If you still have access to your key material then it is probably easier to generate a fresh revocation, and an explicit statement of key compromise is more informative for manual inspection purposes than “None”, so should be encouraged - but from an automated reasoning point of view, they are not distinct.

>> 9.1.  Non-functionality of the "Revocable" Signature Subpacket
>> 
>>   *  Since there is no such thing as a document revocation signature,
>>      this is only applicable to self-signatures and third party
>>      certifications.
> 
> I think this is the purpose of the signature target subpacket.
> 
>  https://www.rfc-editor.org/rfc/rfc9580.html#section-5.2.3.11-3

I don’t think I understand you correctly - are you disagreeing with the statement that the revocable subpacket only applies to self-signatures and third-party certifications?

Thanks,
Andrew.