Internet DRAFT - draft-dkg-openpgp-revocation
draft-dkg-openpgp-revocation
openpgp D. K. Gillmor
Internet-Draft ACLU
Intended status: Informational 17 August 2023
Expires: 18 February 2024
Revocation in OpenPGP
draft-dkg-openpgp-revocation-01
Abstract
Cryptographic revocation is a hard problem. OpenPGP's revocation
mechanisms are imperfect, not fully understood, and not as widely
implemented as they could be. Additionally, some historical OpenPGP
revocation mechanisms simply do not work in certain contexts. This
document provides clarifying guidance on how OpenPGP revocation
works, documents outstanding problems, and introduces a new mechanism
for delegated revocations that improves on previous mechanism.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://dkg.gitlab.io/openpgp-revocation/. Status information for
this document may be found at https://datatracker.ietf.org/doc/draft-
dkg-openpgp-revocation/.
Discussion of this document takes place on the OpenPGP Working Group
mailing list (mailto:openpgp@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/openpgp/. Subscribe at
https://www.ietf.org/mailman/listinfo/openpgp/.
Source for this draft and an issue tracker can be found at
https://gitlab.com/dkg/openpgp-revocation.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Gillmor Expires 18 February 2024 [Page 1]
Internet-Draft Revocation in OpenPGP August 2023
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 February 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. What Can Be Revoked: Keys, Subkeys, Certifications? . . . . . 4
2.1. Instead of Revoking a Certification . . . . . . . . . . . 4
2.2. Instead of Revoking a Subkey . . . . . . . . . . . . . . 5
3. Challenges with OpenPGP Revocation . . . . . . . . . . . . . 5
3.1. Obtaining Revocation Information . . . . . . . . . . . . 5
3.1.1. Revocation Stripping . . . . . . . . . . . . . . . . 5
3.2. Revocations Using Weak Cryptography . . . . . . . . . . . 6
3.3. Revoking Primary Key Binding Signatures . . . . . . . . . 6
3.4. Implications for Revoked Key Material . . . . . . . . . . 6
3.5. Reasons for Revocation Mismatch . . . . . . . . . . . . . 6
3.6. Revocation Key Subpacket Challenges . . . . . . . . . . . 6
3.6.1. Finding the Revocation Key . . . . . . . . . . . . . 7
3.6.2. What If the Revocation Key is Itself Revoked or
Unusable? . . . . . . . . . . . . . . . . . . . . . . 7
3.6.3. Social Graph Leakage . . . . . . . . . . . . . . . . 7
3.6.4. What if the Signature Containing the Revocation Key is
Revoked or Superseded? . . . . . . . . . . . . . . . 7
3.6.5. What can the Revocation Key Revoke? . . . . . . . . . 9
3.7. What About Revocations From the Future? . . . . . . . . . 9
4. Dealing With Revoked Certificates . . . . . . . . . . . . . . 9
5. Hard vs. Soft Revocations . . . . . . . . . . . . . . . . . . 9
5.1. When is Soft Revocation Useful? . . . . . . . . . . . . . 10
6. Revocation Certificates . . . . . . . . . . . . . . . . . . . 10
Gillmor Expires 18 February 2024 [Page 2]
Internet-Draft Revocation in OpenPGP August 2023
6.1. Handling a Revocation Certificate . . . . . . . . . . . . 10
6.2. Publishing a Revocation Certificate . . . . . . . . . . . 11
7. Escrowed Revocation Certificate . . . . . . . . . . . . . . . 11
7.1. Escrowed Hard Revocation Workflow . . . . . . . . . . . . 11
7.2. Escrowed Soft Revocation Workflow . . . . . . . . . . . . 11
7.3. K-of-N Escrowed Revocation . . . . . . . . . . . . . . . 11
8. The Delegated Revoker . . . . . . . . . . . . . . . . . . . . 12
8.1. Delegated Revoker Signature . . . . . . . . . . . . . . . 12
8.1.1. Transmitting a Delegated Revoker Signature in OpenPGP
Certificate . . . . . . . . . . . . . . . . . . . . . 13
8.1.2. "Sensitivity"? . . . . . . . . . . . . . . . . . . . 13
8.2. Delegated Revoker Subpacket . . . . . . . . . . . . . . . 13
8.3. Delegated Revokers Cannot Be Superseded or Revoked . . . 14
8.4. Delegated Revokers Are Independent of Any OpenPGP
Certificate . . . . . . . . . . . . . . . . . . . . . . . 14
8.5. Delegated Revoker Only Issues Key Revocation
Signatures . . . . . . . . . . . . . . . . . . . . . . . 14
8.6. Cryptographic Algorithm Choices . . . . . . . . . . . . . 14
8.7. Reasonable Workflows . . . . . . . . . . . . . . . . . . 14
8.7.1. Delegator Selection . . . . . . . . . . . . . . . . . 15
8.7.2. Delegated Key Selection . . . . . . . . . . . . . . . 15
8.7.3. Delegation Publication . . . . . . . . . . . . . . . 15
8.8. K-of-N Delegated Revokers . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. Subpacket Types: Add Delegated Revoker Row . . . . . . . 15
9.2. Reasons for Revocation: Add Hard vs. Soft Column . . . . 15
9.3. Signature Types: Add Delegated Revoker Row . . . . . . . 15
9.4. Signature Types: Update References . . . . . . . . . . . 16
9.5. Subpacket Types: Update References . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Augmenting SOP For Revocation . . . . . . . . . . . 17
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 17
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Appendix D. Substantive changes to this document . . . . . . . . 17
D.1. Substantive Changes From draft-dkg-openpgp-revocation-00 to
-01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
OpenPGP revocation is complicated. This document attempts to clean
it up and build a consensus around syntax, semantics, use cases, and
workflows.
Gillmor Expires 18 February 2024 [Page 3]
Internet-Draft Revocation in OpenPGP August 2023
The only substantive wire format change is the introduction of the
"Delegated Revoker" subpacket described in Section 8.
1.1. Terminology
The term "OpenPGP Certificate" is used in this document
interchangeably with "OpenPGP Transferable Public Key", as defined in
Section 10.1 of [I-D.ietf-openpgp-crypto-refresh].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. What Can Be Revoked: Keys, Subkeys, Certifications?
There are three kinds of signatures that do revocation: Key
Revocation (0x20), Subkey Revocation (0x28), and Certification
Revocation (0x30).
This document focuses on revoking full OpenPGP certificates (a.k.a.
"Transferable Public Keys") using Key Revocation signatures (0x20).
This document also explicitly deprecates the remaining two signature
types: Subkey Revocation (0x28) and Certification Revocation (0x30).
2.1. Instead of Revoking a Certification
User ID self-certifications and direct-key self-signatures can be
explicitly expired or replaced by the keyholder by issuing a
superseding certification, so the only reason for a certification
revocation is for third-party certifications.
When Alice revokes her certification over Bob's Primary Key and User
ID, what is she saying specifically?
How does Alice's Certification Revocation signature packet get placed
into Bob's certificate?
Why doesn't Alice just issue a superseding certification of her own
over Bob's User ID instead of revoking it?
Gillmor Expires 18 February 2024 [Page 4]
Internet-Draft Revocation in OpenPGP August 2023
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? Alternately, if the
superseding certification has a timestamp of time T exactly, will
verifiers prefer its expiration date or the initial certification's
expiration date (or lack thereof)?
2.2. Instead of Revoking a Subkey
Why bother revoking a subkey? Why not just issue an superseding
Subkey Binding Signature?
FIXME: One reason why revoking a subkey might be nice is if a subkey
has been compromised, _and_ multiple historical subkey bindings have
been made. In that case, to have the same effect the keyholder would
need to issue one superseding expiring Subkey Binding Signature for
each known Subkey Binding Signature, which is kind of a mess.
What happens when a Subkey Binding Signature is revoked, and then
later a new Subkey Binding Signature is made over the same subkey?
3. Challenges with OpenPGP Revocation
This section describes a number of outstanding challenges with
implementing OpenPGP revocation in the state of the field before this
document. Some of these problems are fixed by this document.
3.1. Obtaining Revocation Information
How does the user know that they have the correct revocation status?
Where do they look for revocations from? With what frequency?
When the keyholder changes to a new key, how do they distribute
revocations for older keys?
3.1.1. Revocation Stripping
Given the chance to tamper with an OpenPGP certificate, the simplest
thing that an adversary can do is to strip signature subpackets.
Stripping a revocation signature subpacket is trivial, and the
resulting certificate looks valid.
An OpenPGP implementation needs a reliable channel to fetch
revocation signatures from, and a reliable and well-indexed storage
mechanism to retain them safely to avoid using revoked certificates.
Gillmor Expires 18 February 2024 [Page 5]
Internet-Draft Revocation in OpenPGP August 2023
3.2. Revocations Using Weak Cryptography
What if we find a Key Revocation signature made using SHA1 or MD5?
Should we consider the indicated key revoked?
3.3. Revoking Primary Key Binding Signatures
Primary keys sign Subkey Binding Signatures. Signing-capable subkeys
sign Primary Key Binding Signatures.
Is there ever a scenario where a signing-capable subkey might want to
revoke its own Primary Key Binding Signature?
If so, how is that done?
3.4. Implications for Revoked Key Material
You find a self-revoked primary key, and you find another OpenPGP
certificate in the wild that uses the same key material (but maybe
different creation date, or used as a subkey instead of as a primary
key). Is it acceptable for use?
In certificate with primary key X, there is a revoked subkey Y (it
was revoked by X issuing a valid Subkey Revocation signature). But
the certificate with primary key Z, _also_ has subkey Y. Is subkey Y
valid for the Z certificate?
3.5. 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")?
How should an implementation interpret a Certification Revocation
with a Reason for Revocation with, say, ID 1 ("Key is superseded")?
Do we just say these Revocation signatures are invalid? Do we ignore
the Reasons for Revocation subpacket?
3.6. Revocation Key Subpacket Challenges
The Revocation Key Subpacket is deprecated because it suffers from
several significant challenges in use. The Delegated Revoker
mechanism (described in Section 8) is intended to avoid all of these
problems.
Gillmor Expires 18 February 2024 [Page 6]
Internet-Draft Revocation in OpenPGP August 2023
3.6.1. Finding the Revocation Key
The "Revocation Key" subpacket contains only a fingerprint. If a
verifier observes such a packet, and a Key Revocation Signature that
claims to be issued by the identified key, how does the verifier
obtain the revoking key itself if they do not already have a copy of
it?
3.6.2. What If the Revocation Key is Itself Revoked or Unusable?
What happens if the revocation key's public key packet is known, but
it is not part of a certificate at all?
What if it is enclosed in a certificate, but that certificate
indicates that it is expired, revoked, or otherwise invalid?
The following questions are based on the assumption that key A has
pointed to key B in a "Revocation Key" subpacket.
What if B revokes both itself and key A: is A valid?
What if, instead, B indicates (via the deprecated "Revocation Key"
subpacket) that key A is permitted to revoke key B? In this
scenario, what happens when both A and B revoke each other?
What if A designates that B can revoke A, and B designates that C can
revoke B? In that case, if C revokes B and then B revokes A, is A
still valid?
3.6.3. Social Graph Leakage
If it's possible to find a certificate containing the matching
fingerprint in a deprecated "Revocation Key" subpacket, then an
observer can learn who the keyholder trusts even when no revocation
is needed.
An attacker that wants to target Alice, for example, can observe that
Alice has indicated Bob seems trustworthy if Alice has pointed to
Bob's key's fingerprint with a deprecated "Revocation Key" subpacket.
The attacker might then go after Bob as a way to get to Alice.
3.6.4. What if the Signature Containing the Revocation Key is Revoked
or Superseded?
Section 5.2.3.3 of [RFC4880] states:
Revoking a direct-key signature cancels that signature.
Gillmor Expires 18 February 2024 [Page 7]
Internet-Draft Revocation in OpenPGP August 2023
and
An implementation that encounters multiple self-signatures on the
same object may resolve the ambiguity in any way it sees fit, but
it is RECOMMENDED that priority be given to the most recent self-
signature.
The revised version, Section 5.2.3.10 of
[I-D.ietf-openpgp-crypto-refresh] makes this last sentence even
stronger:
An implementation that encounters multiple self-signatures on the
same object MUST select the most recent valid self-signature, and
ignore all other self-signatures.
Consider the following sequence of events:
* At time t0, key A makes a self-signed Direct Key Signature X on
itself that contains a Revocation Key subpacket pointing to key B.
* At time t1, key A decides to update preferences or expiration date
on itself and issues a new Direct Key Signature Y (which lacks a
Revocation Key subpacket).
* At time t2, key B produces a Key Revocation signature Z to revoke
key A.
The verifier examines this sequence of packets: A, X, Y, Z.
X appears to have been superseded by Y. Should A be considered
revoked?
But what if signature packet Y was a revocation signature instead:
* At time t1, key A creates a Certification Revocation signature Y
over Direct Key signature X.
Or, what if signature packet Y pointed to a _different_ Revocation
Key:
* At time t1, key A creates a Direct Key Signature Y that looks
exactly like X, except that its Revocation Key subpacket points to
key C.
Gillmor Expires 18 February 2024 [Page 8]
Internet-Draft Revocation in OpenPGP August 2023
If, in any of these situations, the verifier does _not_ consider A to
be revoked by Z due to the presence of signature Y, then the
mechanism does not work to protect the keyholder of A. An adversary
who has taken control of A can create a signature packet Y to evade
the third-party revocation capabilities that B is supposed to wield.
If delegating revocation power to a third party is intended to defend
against an adversary, this implies that the guidance about
superseding signatures cannot apply to signature packets that contain
a Revocation Key. But then, if signature X is not revoked or
superseded by signature Y (in whatever form Y takes), how should
implementations deal with the _other_ subpackets in signature X?
3.6.5. What can the Revocation Key Revoke?
Surely it can issue a Key Revocation signature that covers the
primary key itself.
But can it issue a Subkey Revocation signature on behalf of the
primary key? Can it issue a Certification Revocation signature on
behalf of the primary key?
3.7. What About Revocations From the Future?
FIXME: If a Revocation signature appears to have been made in the
future, what should be done with it?
4. Dealing With Revoked Certificates
Implementations MUST NOT encrypt to a revoked certificate.
Implementations MUST NOT accept a signature made by a revoked
certificate as valid unless the revocation is "soft" (see Section 5)
and the timestamp of the signature predates the timestamp of the
revocation. Implementations MUST NOT use secret key material
corresponding to a revoked certificate for signing, unless the secret
key material also corresponds to a non-revoked certificate.
Implementations MAY use the secret key material corresponding to a
revoked certificate.
5. Hard vs. Soft Revocations
Reasons for Revocation subpacket allows different values.
Some of them suggest that a verifier can still accept signatures from
before the timestamp of the Revocation. These are "soft"
revocations.
Gillmor Expires 18 February 2024 [Page 9]
Internet-Draft Revocation in OpenPGP August 2023
All the rest require that a verifier MUST treat the certificate as
"hard" revoked, meaning that even signatures that have creation
timestamps before the creation timestamp of the revocation signature
should themselves be rejected.
5.1. When is Soft Revocation Useful?
Expiration makes just as much sense as a soft revocation in many
circumstances, and is typically better supported.
FIXME: describe the circumstances under which a soft revocation would
be preferable over an expiration. If there are none, explicitly
discourage soft revocation.
6. Revocation Certificates
A revocation certificate indicates that a given primary key is
revoked.
This can take two common forms. Each form is a sequence of OpenPGP
packets:
* A standalone Key Revocation signature packet by key X over X (this
form is valid only for primary keys earlier than version 6)
* Primary Key X + Key Revocation signature by X over X
Additionally, there is a deprecated form:
* Primary Key X + Direct Key Signature with Revocation Key subpacket
pointing to Y + Key Revocation signature by Y over X (this form is
valid only for primary keys earlier than version 6)
This document introduces a new form in Section 8:
* Primary Key X + Delegated Revoker Signature with Delegated Revoker
Subpacket containing Y + Key Revocation signature by Y over X
6.1. Handling a Revocation Certificate
When an implementation observes any of the above forms of revocation
certificate for a certificate with primary key X, it should record it
and indicate that X has been revoked and is no longer to be used,
along with all of its User IDs and Subkeys.
Gillmor Expires 18 February 2024 [Page 10]
Internet-Draft Revocation in OpenPGP August 2023
6.2. Publishing a Revocation Certificate
FIXME: talk about interactions with HKP, VKS, WKD, OPENPGPKEY (DANE),
or other key discovery methods?
7. Escrowed Revocation Certificate
An escrowed revocation certificate is just a valid revocation
certificate that is not published. The parties who can retrieve or
reassemble the escrowed revocation certificate can publish it to
inform the rest of the world that the certificate has been revoked.
It is described in Section 13.9 of [I-D.ietf-openpgp-crypto-refresh].
In what circumstances does escrowed revocation work? When is it
inappropriate?
7.1. Escrowed Hard Revocation Workflow
An escrowed hard revocation certificate covers the use case where
where the keyholder has lost control of the secret key material, and
someone besides the keyholder may have gotten access to the secret
key material.
At key creation time, keyholder creates a hard revocation
certificate. Optionally, they encrypt it to a set of trusted
participants. The keyholder stores the revocation certificate
somewhere they or one of the trusted participants will be able to
access it.
If the keyholder sends it to any trusted participant immediately,
that participant can trigger a revocation any time they like. In
this case, the keyholder and the trusted participants should clarify
between themselves what an appropriate signal should be for when the
trusted participant should act
If physical access is retained by the keyholder, then the keyholder
has to be capable of consenting for the revocation to be published.
7.2. Escrowed Soft Revocation Workflow
Do regular updates of the escrowed revocation (e.g. after each
signing). Store them somewhere safe?
7.3. K-of-N Escrowed Revocation
FIXME: how to split an escrowed revocation certificate among N
parties so that any K of them can reconstruct it.
Gillmor Expires 18 February 2024 [Page 11]
Internet-Draft Revocation in OpenPGP August 2023
8. The Delegated Revoker
[ See also https://gitlab.com/openpgp-wg/
rfc4880bis/-/merge_requests/18 where this was originally specified,
in a slightly different form ]
This document introduces a new mechanism for permitting a distinct
key to revoke an OpenPGP certificate. It should effectively replace
the deprecated "Revocation Key subpacket", and should resolve the
concerns described in {#revocation-key-subpacket-challenges}.
It uses a novel signature type and a novel subpacket type, is self-
contained, irrevocable, and can only be used to revoke the entire
OpenPGP certificate rooted in the primary key it corresponds to.
8.1. Delegated Revoker Signature
This introduces a new Signature Type, "Delegated Revoker Signature"
with type ID TBD.
This signature type is made over data structured in the same way as a
Direct Key Signature, but it does not supersede or replace any other
signature, and it cannot be revoked or superseded itself. It is a
permanent delegation.
A Delegated Revoker Signature MUST be made over the primary key of a
given certificate, and its hashed subpackets area MUST contain
exactly one each of the following four subpackets:
* Signature Creation Time (see Section 5.2.3.11 of
[I-D.ietf-openpgp-crypto-refresh])
* Issuer Fingerprint (see Section 5.2.3.35 of
[I-D.ietf-openpgp-crypto-refresh])
* Revocable (see Section 5.2.3.20 of
[I-D.ietf-openpgp-crypto-refresh])
* Delegated Revoker (defined in Section 8.2 of this document)
The Issuer Fingerprint subpacket contains the fingerprint of the
primary key that is asserting this delegation. The Revocable
subpacket flag MUST be set to 0. All subpackets MUST be marked as
Critical.
FIXME: What should a verifier do if the set of hashed subpackets does
not match this list?
Gillmor Expires 18 February 2024 [Page 12]
Internet-Draft Revocation in OpenPGP August 2023
8.1.1. Transmitting a Delegated Revoker Signature in OpenPGP
Certificate
The Delegated Revoker Signature packet can be placed in an OpenPGP
certificate immediately after the Primary Key packet, before any Key
Revocation Signature or Direct Key Signature packet.
FIXME: test implementations with this placement strategy to see
whether they choke on the certificate. If this does not work,
consider recommending its inclusion in an unhashed Embedded Signature
subpacket the relevant associated Key Revocation Signature packet (if
it is travelling with the revocation), or in such a subpacket of a
Direct Key Signature packet directly.
8.1.2. "Sensitivity"?
FIXME: how do we deal with avoiding a leak of the existence of this
relationship (e.g., the "Sensitive" bit in the deprecated "Revocaton
Key" subpacket)? Do we need to?
Someone concerned about the risk of social graph leakage (see
Section 3.6.3) can simply mint a new secret key and encrypt its
corresponding Secret Key packet to their preferred revoker.
Or should we add an "Exportable" subpacket to the list above and
describe its syntax more explicitly?
Alternately: what if we said that this is simply _always_ treated as
sensitive, in that without explicitly being part of the described
workflow, it must not be transmitted except in the presence of a
valid revocation? This puts the burden on the holder of the secret
key to keep a copy of the delegation lying around, which is a novel
use case.
8.2. Delegated Revoker Subpacket
The Delegated Revoker Subpacket has type ID 36.
It is only valid in the hashed subpackets section of a Delegated
Revoker Signature (see Section 8.1) over a primary key. It MUST be
marked as Critical.
The contents of this subpacket are a full Public Key packet, see
Section 5.5.1.1 of [I-D.ietf-openpgp-crypto-refresh].
The embedded Public Key packet MUST be signing-capable.
Gillmor Expires 18 February 2024 [Page 13]
Internet-Draft Revocation in OpenPGP August 2023
8.3. Delegated Revokers Cannot Be Superseded or Revoked
Unlike other OpenPGP Signature packets, a Delegated Revoker Signature
cannot be revoked, and is not superseded by any other Signature
packet, including other Delegated Revoker Signature packets. If
multiple valid Delegated Revoker Signatures are issued by a primary
key X, they are all capable of issuing Key Revocation signatures over
X on behalf of X.
8.4. Delegated Revokers Are Independent of Any OpenPGP Certificate
This Public Key MAY be the same Public Key packet that is the root of
a larger OpenPGP certificate, but it need not be. In the Delegated
Revoker context, this Public Key packet is used on its own,
regardless of the status of any matching OpenPGP certificate.
8.5. Delegated Revoker Only Issues Key Revocation Signatures
If an OpenPGP certificate with primary key X has an associated
Delegated Revoker containing Public Key Y, that only indicates that
the Y MAY make a valid Key Revocation signature on behalf of X,
revoking X itself.
The Delegated Revoker Public Key (Y in the example above) MUST NOT be
used to validate any other type of signature associated with that
OpenPGP certificate.
FIXME: should we constrain the types of Key Revocations it can issue
(i.e., the contents of any Reason for Revocation subpackets, or
"hard" or "soft" choices)?
8.6. Cryptographic Algorithm Choices
FIXME: What if the Delegated Revoker Signature is made over a digest
algorithm that is deemed unsafe in the future? FIXME: What if the
embedded Public Key Packet is known to be weak or compromised?
8.7. Reasonable Workflows
The Delegated Revoker mechanism is only useful for a potential
scenario where the keyholder has lost control of the primary secret
key. Otherwise, the keyholder could simply issue the desired Key
Revocation signature (type 0x20) directly.
If the keyholder needs a hard revocation, and they have access to an
escrowed Key Revocation signature, they can use that.
So the circumstances where a Delegated Revoker is relevant
Gillmor Expires 18 February 2024 [Page 14]
Internet-Draft Revocation in OpenPGP August 2023
8.7.1. Delegator Selection
Keyholder needs to choose who they think will be responsible for
handling the delegated responsibility of revoking when the time is
needed. This could be another individual, or it could be a machine
that has distinct security and operational characteristics from the
machine that holds the primary key.
8.7.2. Delegated Key Selection
* Keyholder generates revocation secret key
* Keyholder selects signing-capable key or subkey already belonging
to delegate
8.7.3. Delegation Publication
* private communication
* public (keyservers)
8.8. K-of-N Delegated Revokers
FIXME: should this document outline how a group of trusted parties
could effectively revoke a given certificate that authorized them to
do so?
9. IANA Considerations
This draft asks IANA to do several things, all within the OpenPGP
protocol group.
9.1. Subpacket Types: Add Delegated Revoker Row
Add an entry "Delegated Revoker" to OpenPGP subpackets, type 36,
referencing this document, Section 8.2.
9.2. Reasons for Revocation: Add Hard vs. Soft Column
The "Reasons for Revocation Code" registry should add a column to
indicate "Hard/Soft". Only "Key is Superseded" and "Key is retired
and no longer used" are marked "Soft". All other values should be
treated as "Hard".
9.3. Signature Types: Add Delegated Revoker Row
Add an entry "Delegated Revoker Signature" to OpenPGP Signature
Types, type ID TBD, referencing this document, Section 8.1.
Gillmor Expires 18 February 2024 [Page 15]
Internet-Draft Revocation in OpenPGP August 2023
9.4. Signature Types: Update References
"Signature Types" registry entries should have References updated:
* 0x20 references should additionally point to this document
* 0x28 references should be marked "deprecated", and additionally
point to this document, Section 2.2
* 0x30 references should be marked "deprecated", and additionally
point to this document, Section 2.1
9.5. Subpacket Types: Update References
The "Reason for Revocation" entry in the "Subpacket Types" registry
should have its References column updated to point to this document.
10. Security Considerations
This document describes ways that the OpenPGP ecosystem deals with
revoked certificates. Revocation is a security measure because it is
a method of last resort for dealing with cryptographic credentials
that are known to have failed for one reason or another.
The entire document is therefore focused on security. Implementers
who ignore this guidance may either allow known-bad key material to
be used (by ignoring a valid revocation signature) or may issue
revocation signatures that other implementations are likely to
ignore.
11. References
11.1. Normative References
[I-D.ietf-openpgp-crypto-refresh]
Wouters, P., Huigens, D., Winter, J., and N. Yutaka,
"OpenPGP", Work in Progress, Internet-Draft, draft-ietf-
openpgp-crypto-refresh-10, 21 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-
crypto-refresh-10>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Gillmor Expires 18 February 2024 [Page 16]
Internet-Draft Revocation in OpenPGP August 2023
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007,
<https://www.rfc-editor.org/info/rfc4880>.
Appendix A. Augmenting SOP For Revocation
FIXME: Can all of the plausible workflows described in this document
be done with the Stateless OpenPGP Interface? If not, what is
missing?
Appendix B. Test Vectors
FIXME: This document should include several different valid OpenPGP
Revocation Certificates.
Appendix C. Acknowledgements
Phil Zimmermann motivated the Delegated Revoker work.
Appendix D. Substantive changes to this document
RFC Editor Note: Please delete this section before publication.
D.1. Substantive Changes From draft-dkg-openpgp-revocation-00 to -01
* Enumerate problems with Revocation Key subpacket, including
superseded signatures
* Offer doubt about deprecating Subkey Revocation and Certification
Revocation (maybe a future version will un-deprecate with clearer
guidance?)
* Change mechanism from Direct Key Signature to dedicated Delegated
Revoker Signature Type
Author's Address
Daniel Kahn Gillmor
ACLU
Email: dkg@fifthhorseman.net
Gillmor Expires 18 February 2024 [Page 17]
