openpgp D. K. Gillmor Internet-Draft ACLU Intended status: Informational 16 August 2023 Expires: 17 February 2024 Revocation in OpenPGP draft-dkg-openpgp-revocation-00 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 17 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 17 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 . . . . . . . . . . . . . . . . . . . . . . . 3 2. What Can Be Revoked: Keys, Subkeys, Certifications? . . . . . 3 2.1. Instead of Revoking a Certification . . . . . . . . . . . 4 2.2. Instead of Revoking a Subkey . . . . . . . . . . . . . . 4 3. Challenges with OpenPGP Revocation . . . . . . . . . . . . . 4 3.1. Obtaining Revocation Information . . . . . . . . . . . . 4 3.2. Verifying Revocations . . . . . . . . . . . . . . . . . . 5 3.3. Social Graph Leakage . . . . . . . . . . . . . . . . . . 5 3.4. Revocations Using Weak Cryptography . . . . . . . . . . . 5 3.5. Revocations Made By Revoked Keys . . . . . . . . . . . . 5 3.6. Revoking Primary Key Binding Signatures . . . . . . . . . 5 3.7. Implications for Revoked Key Material . . . . . . . . . . 6 3.8. Reasons for Revocation Mismatch . . . . . . . . . . . . . 6 3.9. What About Future Revocations? . . . . . . . . . . . . . 6 4. Expiration as a Revocation Alternative . . . . . . . . . . . 6 5. Dealing With Revoked Certificates . . . . . . . . . . . . . . 6 6. Hard vs. Soft Revocations . . . . . . . . . . . . . . . . . . 7 7. Revocation Certificates . . . . . . . . . . . . . . . . . . . 7 7.1. Handling a Revocation Certificate . . . . . . . . . . . . 7 7.2. Publishing a Revocation Certificate . . . . . . . . . . . 8 8. Escrowed Revocation Certificate . . . . . . . . . . . . . . . 8 8.1. Escrowed Hard Revocation Workflow . . . . . . . . . . . . 8 8.2. Escrowed Soft Revocation Workflow . . . . . . . . . . . . 8 8.3. K-of-N Escrowed Revocation . . . . . . . . . . . . . . . 8 Gillmor Expires 17 February 2024 [Page 2] Internet-Draft Revocation in OpenPGP August 2023 9. The Delegated Revoker Subpacket . . . . . . . . . . . . . . . 9 9.1. Superseding/Overriding the Delegated Revoker Subpacket? . . . . . . . . . . . . . . . . . . . . . . . 9 9.2. Reasonable Workflows . . . . . . . . . . . . . . . . . . 9 9.2.1. Delegator Selection . . . . . . . . . . . . . . . . . 9 9.2.2. Delegated Key Selection . . . . . . . . . . . . . . . 9 9.2.3. Delegation Publication . . . . . . . . . . . . . . . 10 9.3. Interaction with Specific Subpackets . . . . . . . . . . 10 9.3.1. Signature Expiration Subpacket . . . . . . . . . . . 10 9.3.2. Exportable Certification Subpacket . . . . . . . . . 10 9.4. K-of-N Delegated Revokers . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10.1. Subpacket Types: Add Delegated Revoker Row . . . . . . . 10 10.2. Reasons for Revocation: Add Hard vs. Soft Column . . . . 10 10.3. Signature Types: Update References . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 12. Normative References . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Appendix C. Substantive changes to this document . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction OpenPGP revocation is complicated. This document attempts to clean it up and build a consensus around syntax, semantics, use cases, and workflows. The only substantive wire format change is the introduction of the "Delegated Revoker" subpacket described in Section 9. 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 User ID Revocation (0x30). Gillmor Expires 17 February 2024 [Page 3] Internet-Draft Revocation in OpenPGP August 2023 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 User ID Revocation (0x30). 2.1. Instead of Revoking a Certification User ID self-certifications can be explicitly expired or replaced by the keyholder by issuing a superseding certification, so the only possible 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? 2.2. Instead of Revoking a Subkey Why bother revoking a subkey? Why not just issue an superseding Subkey Binding Signature? 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? How does the keyholder distribute revocations for older keys? Gillmor Expires 17 February 2024 [Page 4] Internet-Draft Revocation in OpenPGP August 2023 3.2. Verifying Revocations The deprecated "Revocation Key" subpacket contains only a fingerprint. If the deprecated "Revocation Key" subpacket is in use, how does the verifier obtain the revoking key if they do not already have a copy of it? What happens if they have a copy of a primary key that matches the fingerprint, but the enclosing certificate indicates that it is expired, revoked, or otherwise invalid? 3.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. 3.4. 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.5. Revocations Made By Revoked Keys It's possible for key A to indicate, using the deprecated "Revocation Key" subpacket, that key B is permitted to revoke key A. 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. Revoking Primary Key Binding Signatures Primary keys sign Subkey Binding Signatures. Signing-capable subkeys sign Primary Key Binding Signatures. Gillmor Expires 17 February 2024 [Page 5] Internet-Draft Revocation in OpenPGP August 2023 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.7. 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.8. 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 ID 1 ("Key is superseded")? Do we just say these Revocation signatures are invalid? 3.9. What About Future Revocations? FIXME: If a Revocation signature appears to have been made in the future, what should be done with it? 4. Expiration as a Revocation Alternative Expiration makes just as much sense as a soft revocation in many circumstances, and is typically better supported. 5. 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 6) 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. Gillmor Expires 17 February 2024 [Page 6] Internet-Draft Revocation in OpenPGP August 2023 Implementations MAY use the secret key material corresponding to a revoked certificate. 6. 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. 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. 7. 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 9: * Primary Key X + Direct Key Signature with Delegated Revoker subpacket containing Y + Key Revocation signature by Y over X 7.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 17 February 2024 [Page 7] Internet-Draft Revocation in OpenPGP August 2023 7.2. Publishing a Revocation Certificate FIXME: talk about interactions with HKP, VKS, WKD, OPENPGPKEY (DANE), or other key discovery methods? 8. 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. In what circumstances does escrowed revocation work? When is it inappropriate? 8.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. 8.2. Escrowed Soft Revocation Workflow Do regular updates of the escrowed revocation (e.g. after each signing). Store them somewhere safe? 8.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 17 February 2024 [Page 8] Internet-Draft Revocation in OpenPGP August 2023 9. The Delegated Revoker Subpacket See https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/18 This should effectively replace the deprecated "Revocation Key subpacket". Signature subpacket type ID 36. Only valid in the hashed subpackets section of a direct-key self-signature over a primary key. Contains a full public key packet. (FIXME: do we include a class octet with a "sensitive bit", as the "Revocation Key subpacket" does, or can we just rely on the exportable certification subpacket as described in Section 9.3.2?) 9.1. Superseding/Overriding the Delegated Revoker Subpacket? If the delegated revoker subpacket is in a direct key signature made at time T0, and another direct key signature packet was made at time T1 that lacks a delegated revoker subpacket, what happens? 9.2. 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 9.2.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. 9.2.2. Delegated Key Selection * Keyholder generates revocation secret key * Keyholder selects signing-capable key or subkey already belonging to delegate Gillmor Expires 17 February 2024 [Page 9] Internet-Draft Revocation in OpenPGP August 2023 9.2.3. Delegation Publication * private communication * public (keyservers) 9.3. Interaction with Specific Subpackets Some signature subpackets might have additional meaning when coupled with a Delegated Revoker subpacket in the hashed subpackets section of a single signature 9.3.1. Signature Expiration Subpacket FIXME: what should be done if the signature expires? 9.3.2. Exportable Certification Subpacket (Should an observed non-exportable delegated revocation subpacket, when combined with an actual revocation, be treated as exportable?) 9.4. 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? 10. IANA Considerations This draft asks IANA to do several things, all within the OpenPGP protocol group. 10.1. Subpacket Types: Add Delegated Revoker Row Add an entry "Delegated Revoker" to OpenPGP subpackets, type 36, referencing this document, Section 9. 10.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". 10.3. Signature Types: Update References "Signature Types" registry entries should have References updated: Gillmor Expires 17 February 2024 [Page 10] Internet-Draft Revocation in OpenPGP August 2023 * 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 11. 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. 12. 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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Appendix A. Test Vectors FIXME: This document should include several different valid OpenPGP Revocation Certificates. Appendix B. Acknowledgements Phil Zimmermann championed the Delegated Revoker subpacket work. Gillmor Expires 17 February 2024 [Page 11] Internet-Draft Revocation in OpenPGP August 2023 Appendix C. Substantive changes to this document RFC Editor Note: Please delete this section before publication. Author's Address Daniel Kahn Gillmor ACLU Email: dkg@fifthhorseman.net Gillmor Expires 17 February 2024 [Page 12]