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

["Neal H. Walfield" <[e-mail]>]

Hi Andrew, hi dkg,

Thanks for working on this document.  I've looked it over and I agree
with the motivation to nail down the semantics of revocations, and I
like the delegated revocation mechanism.  Some comments are below.

> 2.  What Can Be Revoked: Keys, Subkeys, Certifications?
>
>    *  A Certification Revocation Signature (0x30) revokes:
>
>       -  all previous Certification Signatures (0x10..0x13) over the
>          same primary key and User ID or User Attribute, or
>
>       -  all previous Direct Key Signatures (0x1f) over the same primary
>          key, that were made by the same key that made the revocation.

RFC 9580 includes a signature target packet that allows revoking a
particular signature:

  >  5.2.3.33. Signature Target
  >
  > This subpacket identifies a specific target signature to which a
  > signature refers. For Revocation Signatures, this subpacket provides
  > explicit designation of which signature is being revoked. For a
  > Third-Party Confirmation or Timestamp signature, this designates
  > what signature is signed. All arguments are an identifier of that
  > target signature.

  https://www.rfc-editor.org/rfc/rfc9580.html#section-5.2.3.33

So I think the list is incomplete.  This impacts some further analysis
in particular the claim in section 9 that the "Revocable" Signature
Subpacket is irrelevant.

  https://www.ietf.org/archive/id/draft-dkg-openpgp-revocation-02.html#section-9

> 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

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.

> 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.

You seem to touch on this idea in 2.3.

> 2.2.  Revoking a Subkey
>
> A Subkey packet may be revoked because its private key material has
> been compromised. It is possible for a Subkey to be compromised
> without the Primary Key being affected, for example if the private
> Subkey and Primary Key material are stored on separate devices. In
> such a case, it is not necessary for a Subkey Revocation Signature
> to be generated ahead of time and escrowed, since the Primary Key is
> still usable and can generate a revocation as required.
>
> FIXME: are other kinds of subkey revocation meaningful, see #1 ABG

When rotating subkeys (e.g., sq key rotate), we use "retired" as the
reason for revocation so that artifacts created prior to the
revocation are still considered valid.

> 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."

> 2.3.  Revoking a Certification
>
>    FIXME: Given an initial certification at time T, if the superseding
>    certification has a timestamp of T+1, then will a verifier that cares
>    about the certification still accept signatures from the key based on
>    the User ID that were made exactly at time T?

In Sequoia our answer is yes for soft revocations: soft revocations
created after the reference time are ignored.

> 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/ .

> 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

> 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?

> 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]>.

> 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.

> 3.8.  Revocation Signature Subpacket limitations
>
>    When generating a revocation signature, an implementation:
>
>    *  SHOULD include a Signature Creation Time subpacket

This conflicts with what RFC 9580 says:

  >  5.2.3.11. Signature Creation Time
  >
  > The time the signature was made.This subpacket MUST be present in the hashed area.
  > ...
  >    If a revocation signature does not contain a valid Signature Creation
  >    Time subpacket, a receiving implementation MAY treat it as if it was
  >    created in the infinite past.

  https://www.rfc-editor.org/rfc/rfc9580.html#section-5.2.3.11

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

> 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.

>    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.

> 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.

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

> 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


Thanks for working on this!

:) Neal