< draft-dkg-openpgp-abuse-resistant-keystore-03.txt   draft-dkg-openpgp-abuse-resistant-keystore-04.txt >
openpgp D. Gillmor openpgp D. Gillmor
Internet-Draft ACLU Internet-Draft ACLU
Intended status: Informational April 19, 2019 Intended status: Informational August 22, 2019
Expires: October 21, 2019 Expires: February 23, 2020
Abuse-Resistant OpenPGP Keystores Abuse-Resistant OpenPGP Keystores
draft-dkg-openpgp-abuse-resistant-keystore-03 draft-dkg-openpgp-abuse-resistant-keystore-04
Abstract Abstract
OpenPGP transferable public keys are composite certificates, made up OpenPGP transferable public keys are composite certificates, made up
of primary keys, direct key signatures, user IDs, identity of primary keys, direct key signatures, user IDs, identity
certifications ("signature packets"), subkeys, and so on. They are certifications ("signature packets"), subkeys, and so on. They are
often assembled by merging multiple certificates that all share the often assembled by merging multiple certificates that all share the
same primary key, and are distributed in public keystores. same primary key, and are distributed in public keystores.
Unfortunately, since many keystores permit any third-party to add a Unfortunately, since many keystores permit any third-party to add a
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 21, 2019. This Internet-Draft will expire on February 23, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Certificate Flooding . . . . . . . . . . . . . . . . . . 7 2.1. Certificate Flooding . . . . . . . . . . . . . . . . . . 7
2.2. User ID Flooding . . . . . . . . . . . . . . . . . . . . 8 2.2. User ID Flooding . . . . . . . . . . . . . . . . . . . . 8
2.3. Fingerprint Flooding . . . . . . . . . . . . . . . . . . 8 2.3. Fingerprint Flooding . . . . . . . . . . . . . . . . . . 8
2.4. Keystore Flooding . . . . . . . . . . . . . . . . . . . . 9 2.4. Keystore Flooding . . . . . . . . . . . . . . . . . . . . 9
2.5. Toxic Data . . . . . . . . . . . . . . . . . . . . . . . 9 2.5. Toxic Data . . . . . . . . . . . . . . . . . . . . . . . 9
3. Keystore Interfaces . . . . . . . . . . . . . . . . . . . . . 9 3. Keystore Interfaces . . . . . . . . . . . . . . . . . . . . . 9
3.1. Certificate Update . . . . . . . . . . . . . . . . . . . 10 3.1. Certificate Refresh . . . . . . . . . . . . . . . . . . . 10
3.2. Certificate Discovery . . . . . . . . . . . . . . . . . . 10 3.2. Certificate Discovery . . . . . . . . . . . . . . . . . . 10
3.3. Certificate Lookup . . . . . . . . . . . . . . . . . . . 11 3.3. Certificate Lookup . . . . . . . . . . . . . . . . . . . 11
3.3.1. Full User ID Lookup . . . . . . . . . . . . . . . . . 11 3.3.1. Full User ID Lookup . . . . . . . . . . . . . . . . . 11
3.3.2. E-mail Address Lookup . . . . . . . . . . . . . . . . 12 3.3.2. E-mail Address Lookup . . . . . . . . . . . . . . . . 12
3.3.3. Other Lookup Mechanisms . . . . . . . . . . . . . . . 12 3.3.3. Other Lookup Mechanisms . . . . . . . . . . . . . . . 12
3.4. Certificate Validation . . . . . . . . . . . . . . . . . 12 3.4. Certificate Validation . . . . . . . . . . . . . . . . . 12
3.5. Certificate Submission . . . . . . . . . . . . . . . . . 14 3.5. Certificate Submission . . . . . . . . . . . . . . . . . 14
4. Simple Mitigations . . . . . . . . . . . . . . . . . . . . . 14 4. Simple Mitigations . . . . . . . . . . . . . . . . . . . . . 14
4.1. Decline Large Packets . . . . . . . . . . . . . . . . . . 14 4.1. Decline Large Packets . . . . . . . . . . . . . . . . . . 14
4.2. Enforce Strict User IDs . . . . . . . . . . . . . . . . . 15 4.2. Enforce Strict User IDs . . . . . . . . . . . . . . . . . 15
skipping to change at page 3, line 6 skipping to change at page 3, line 6
4.4.1. Issuer Fingerprint . . . . . . . . . . . . . . . . . 15 4.4.1. Issuer Fingerprint . . . . . . . . . . . . . . . . . 15
4.4.2. Cross-sigs . . . . . . . . . . . . . . . . . . . . . 15 4.4.2. Cross-sigs . . . . . . . . . . . . . . . . . . . . . 15
4.4.3. First-party Attestations . . . . . . . . . . . . . . 16 4.4.3. First-party Attestations . . . . . . . . . . . . . . 16
4.5. Decline User Attributes . . . . . . . . . . . . . . . . . 16 4.5. Decline User Attributes . . . . . . . . . . . . . . . . . 16
4.6. Decline Non-exportable Certifications . . . . . . . . . . 16 4.6. Decline Non-exportable Certifications . . . . . . . . . . 16
4.7. Decline Data From the Future . . . . . . . . . . . . . . 16 4.7. Decline Data From the Future . . . . . . . . . . . . . . 16
4.8. Accept Only Profiled Certifications . . . . . . . . . . . 16 4.8. Accept Only Profiled Certifications . . . . . . . . . . . 16
4.9. Accept Only Certificates Issued by Designated Authorities 17 4.9. Accept Only Certificates Issued by Designated Authorities 17
4.10. Decline Packets by Blocklist . . . . . . . . . . . . . . 17 4.10. Decline Packets by Blocklist . . . . . . . . . . . . . . 17
5. Retrieval-time Mitigations . . . . . . . . . . . . . . . . . 18 5. Retrieval-time Mitigations . . . . . . . . . . . . . . . . . 18
5.1. Redacting User IDs . . . . . . . . . . . . . . . . . . . 19 5.1. Redacting User IDs . . . . . . . . . . . . . . . . . . . 18
5.1.1. Certificate Update with Redacted User IDs . . . . . . 19 5.1.1. Certificate Refresh with Redacted User IDs . . . . . 19
5.1.2. Certificate Discovery with Redacted User IDs . . . . 19 5.1.2. Certificate Discovery with Redacted User IDs . . . . 19
5.1.3. Certificate Lookup with Redacted User IDs . . . . . . 20 5.1.3. Certificate Lookup with Redacted User IDs . . . . . . 20
5.1.4. Hinting Redacted User IDs . . . . . . . . . . . . . . 20 5.1.4. Hinting Redacted User IDs . . . . . . . . . . . . . . 20
5.1.5. User ID Recovery by Client Brute Force . . . . . . . 21 5.1.5. User ID Recovery by Client Brute Force . . . . . . . 21
5.2. Primary-key Only Certificate Update . . . . . . . . . . . 21 5.2. Primary-key Only Certificate Refresh . . . . . . . . . . 21
5.3. Require Valid Cross-Sigs for Certificate Discovery . . . 21 5.3. Require Valid Cross-Sigs for Certificate Discovery . . . 21
6. Contextual Mitigations . . . . . . . . . . . . . . . . . . . 22 6. Contextual Mitigations . . . . . . . . . . . . . . . . . . . 22
6.1. Accept Only Cryptographically-verifiable Certifications . 22 6.1. Accept Only Cryptographically-verifiable Certifications . 22
6.2. Accept Only Certificates Issued by Known Certificates . . 23 6.2. Accept Only Certificates Issued by Known Certificates . . 23
6.3. Rate-limit Submissions by IP Address . . . . . . . . . . 23 6.3. Rate-limit Submissions by IP Address . . . . . . . . . . 23
6.4. Accept Certificates Based on Exterior Process . . . . . . 23 6.4. Accept Certificates Based on Exterior Process . . . . . . 24
6.5. Accept Certificates by E-mail Validation . . . . . . . . 24 6.5. Accept Certificates by E-mail Validation . . . . . . . . 24
7. Non-append-only mitigations . . . . . . . . . . . . . . . . . 24 7. Non-append-only mitigations . . . . . . . . . . . . . . . . . 24
7.1. Drop Superseded Signatures . . . . . . . . . . . . . . . 25 7.1. Drop Superseded Signatures . . . . . . . . . . . . . . . 25
7.2. Drop Expired Signatures . . . . . . . . . . . . . . . . . 25 7.2. Drop Expired Signatures . . . . . . . . . . . . . . . . . 25
7.3. Drop Dangling User IDs, User Attributes, and Subkeys . . 25 7.3. Drop Dangling User IDs, User Attributes, and Subkeys . . 25
7.4. Drop All Other Elements of a Directly-Revoked Certificate 26 7.4. Drop All Other Elements of a Directly-Revoked Certificate 26
7.5. Implicit Expiration Date . . . . . . . . . . . . . . . . 26 7.5. Implicit Expiration Date . . . . . . . . . . . . . . . . 26
8. Updates-only Keystores . . . . . . . . . . . . . . . . . . . 27 8. Primary Key Sovereignty . . . . . . . . . . . . . . . . . . . 27
9. First-party-only Keystores . . . . . . . . . . . . . . . . . 27 8.1. Refresh-only Keystores . . . . . . . . . . . . . . . . . 27
9.1. First-party-only Without User IDs . . . . . . . . . . . . 28 8.2. First-party-only Keystores . . . . . . . . . . . . . . . 28
10. First-party-attested Third-party Certifications . . . . . . . 28 8.2.1. First-party-only Without User IDs . . . . . . . . . . 29
10.1. Key Server Preferences "No-modify" . . . . . . . . . . . 29 8.3. First-party-attested Third-party Certifications . . . . . 29
10.2. Client Interactions . . . . . . . . . . . . . . . . . . 30 8.3.1. Client Interactions . . . . . . . . . . . . . . . . . 30
11. Keystore Client Best Practices . . . . . . . . . . . . . . . 30 8.3.2. Attestation Revocations . . . . . . . . . . . . . . . 31
11.1. Use Constrained Keystores for Lookup . . . . . . . . . . 30 8.3.3. Distribution of Attestation Revocations . . . . . . . 32
11.2. Normalize Addresses and User IDs for Lookup . . . . . . 30 8.3.4. Revoking Third-party Certifications . . . . . . . . . 33
11.3. Avoid Fuzzy Lookups . . . . . . . . . . . . . . . . . . 31 9. Keystore Client Best Practices . . . . . . . . . . . . . . . 35
11.4. Prefer Full Fingerprint for Discovery and Update . . . . 31 9.1. Use Constrained Keystores for Lookup . . . . . . . . . . 35
11.5. Use Caution with Keystore-provided Validation . . . . . 31 9.2. Normalize Addresses and User IDs for Lookup . . . . . . . 35
12. Certificate Generation and Management Best Practices . . . . 32 9.3. Avoid Fuzzy Lookups . . . . . . . . . . . . . . . . . . . 36
12.1. Canonicalized E-Mail Addresses . . . . . . . . . . . . . 32 9.4. Prefer Full Fingerprint for Discovery and Refresh . . . . 36
12.2. Normalized User IDs . . . . . . . . . . . . . . . . . . 32 9.5. Use Caution with Keystore-provided Validation . . . . . . 36
12.3. Avoid Large User Attributes . . . . . . . . . . . . . . 32 10. Certificate Generation and Management Best Practices . . . . 37
12.4. Provide Cross-Sigs . . . . . . . . . . . . . . . . . . . 33 10.1. Canonicalized E-Mail Addresses . . . . . . . . . . . . . 37
12.5. Provide Issuer Fingerprint Subpackets . . . . . . . . . 33 10.2. Normalized User IDs . . . . . . . . . . . . . . . . . . 37
12.6. Put Cross-Sigs and Issuer Fingerprint in Hashed 10.3. Avoid Large User Attributes . . . . . . . . . . . . . . 37
Subpackets . . . . . . . . . . . . . . . . . . . . . . . 33 10.4. Provide Cross-Sigs . . . . . . . . . . . . . . . . . . . 37
12.7. Submit Certificates to Restricted, Lookup-Capable 10.5. Provide Issuer Fingerprint Subpackets . . . . . . . . . 38
Keystores . . . . . . . . . . . . . . . . . . . . . . . 33 10.6. Put Cross-Sigs and Issuer Fingerprint in Hashed
13. Side Effects and Ecosystem Impacts . . . . . . . . . . . . . 33 Subpackets . . . . . . . . . . . . . . . . . . . . . . . 38
13.1. Designated Revoker . . . . . . . . . . . . . . . . . . . 33 10.7. Submit Certificates to Restricted, Lookup-Capable
13.2. Key IDs vs. Fingerprints in Certificate Discovery . . . 34 Keystores . . . . . . . . . . . . . . . . . . . . . . . 38
13.3. In-band Certificates . . . . . . . . . . . . . . . . . . 34 11. Side Effects and Ecosystem Impacts . . . . . . . . . . . . . 38
13.3.1. In-band Certificate Minimization and Validity . . . 35 11.1. Designated Revoker . . . . . . . . . . . . . . . . . . . 38
13.4. Certification-capable Subkeys . . . . . . . . . . . . . 36 11.2. Key IDs vs. Fingerprints in Certificate Discovery . . . 39
13.5. Assessing Certificates in the Past . . . . . . . . . . . 36 11.3. In-band Certificates . . . . . . . . . . . . . . . . . . 39
13.5.1. Point-in-time Certificate Evaluation . . . . . . . . 37 11.3.1. In-band Certificate Minimization and Validity . . . 40
13.5.2. Signature Verification and Non-append-only Keystores 37 11.4. Certification-capable Subkeys . . . . . . . . . . . . . 41
13.6. Global Append-only Ledgers ("Blockchain") . . . . . . . 37 11.5. Assessing Certificates in the Past . . . . . . . . . . . 41
13.7. Certificate Lookup for Identity Monitoring . . . . . . . 39 11.5.1. Point-in-time Certificate Evaluation . . . . . . . . 41
14. OpenPGP details . . . . . . . . . . . . . . . . . . . . . . . 39 11.5.2. Signature Verification and Non-append-only Keystores 42
14.1. Revocations . . . . . . . . . . . . . . . . . . . . . . 39 11.6. Global Append-only Ledgers ("Blockchain") . . . . . . . 42
14.2. User ID Conventions . . . . . . . . . . . . . . . . . . 40 11.7. Certificate Lookup for Identity Monitoring . . . . . . . 43
14.3. E-mail Address Canonicalization . . . . . . . . . . . . 41 12. OpenPGP details . . . . . . . . . . . . . . . . . . . . . . . 44
14.3.1. Disallowing Non-UTF-8 Local Parts . . . . . . . . . 41 12.1. Revocations . . . . . . . . . . . . . . . . . . . . . . 44
14.3.2. Domain Canonicalization . . . . . . . . . . . . . . 41 12.2. User ID Conventions . . . . . . . . . . . . . . . . . . 45
14.3.3. Local Part Canonicalization . . . . . . . . . . . . 41 12.3. E-mail Address Canonicalization . . . . . . . . . . . . 46
15. Security Considerations . . . . . . . . . . . . . . . . . . . 41 12.3.1. Disallowing Non-UTF-8 Local Parts . . . . . . . . . 46
15.1. Tension Between Unrestricted Uploads and Certificate 12.3.2. Domain Canonicalization . . . . . . . . . . . . . . 46
Lookup . . . . . . . . . . . . . . . . . . . . . . . . . 42 12.3.3. Local Part Canonicalization . . . . . . . . . . . . 46
16. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42 13. Security Considerations . . . . . . . . . . . . . . . . . . . 46
16.1. Publishing Identity Information . . . . . . . . . . . . 42 13.1. Tension Between Unrestricted Uploads and Certificate
16.2. Social Graph . . . . . . . . . . . . . . . . . . . . . . 43 Lookup . . . . . . . . . . . . . . . . . . . . . . . . . 47
16.3. Tracking Clients by Queries . . . . . . . . . . . . . . 43 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 47
16.4. "Live" Certificate Validation Leaks Client Activity . . 44 14.1. Publishing Identity Information . . . . . . . . . . . . 47
16.5. Certificate Discovery Leaks Client Activity . . . . . . 44 14.2. Social Graph . . . . . . . . . . . . . . . . . . . . . . 48
16.6. Certificate Update Leaks Client Activity . . . . . . . . 45 14.3. Tracking Clients by Queries . . . . . . . . . . . . . . 48
16.7. Distinct Keystore Interfaces Leak Client Context and 14.4. "Live" Certificate Validation Leaks Client Activity . . 49
Intent . . . . . . . . . . . . . . . . . . . . . . . . . 45 14.5. Certificate Discovery Leaks Client Activity . . . . . . 49
16.8. Cleartext Queries . . . . . . . . . . . . . . . . . . . 46 14.6. Certificate Refresh Leaks Client Activity . . . . . . . 50
16.9. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 46 14.7. Distinct Keystore Interfaces Leak Client Context and
17. User Considerations . . . . . . . . . . . . . . . . . . . . . 46 Intent . . . . . . . . . . . . . . . . . . . . . . . . . 50
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 14.8. Cleartext Queries . . . . . . . . . . . . . . . . . . . 51
19. Document Considerations . . . . . . . . . . . . . . . . . . . 47 14.9. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 51
19.1. Document History . . . . . . . . . . . . . . . . . . . . 47 15. User Considerations . . . . . . . . . . . . . . . . . . . . . 51
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 17. Document Considerations . . . . . . . . . . . . . . . . . . . 52
21.1. Normative References . . . . . . . . . . . . . . . . . . 50 17.1. Document History . . . . . . . . . . . . . . . . . . . . 52
21.2. Informative References . . . . . . . . . . . . . . . . . 50 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 52 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
19.1. Normative References . . . . . . . . . . . . . . . . . . 55
19.2. Informative References . . . . . . . . . . . . . . . . . 56
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 5, line 30 skipping to change at page 5, line 32
"issuer". The primary key over which the certification is made is "issuer". The primary key over which the certification is made is
known as the "subject". known as the "subject".
o A "first-party certification" is issued by the primary key of a o A "first-party certification" is issued by the primary key of a
certificate, and binds itself to a user ID in the certificate. certificate, and binds itself to a user ID in the certificate.
That is, the issuer is the same as the subject. This is sometimes That is, the issuer is the same as the subject. This is sometimes
referred to as a "self-sig". referred to as a "self-sig".
o A "third-party certification" is a made over a primary key and o A "third-party certification" is a made over a primary key and
user ID by some other certification-capable primary key. That is, user ID by some other certification-capable primary key. That is,
the issuer is different than the subject. (The elusive "second- the issuer is different than the subject. The elusive "second-
party" is presumed to be the verifier who is trying to interpret party" is presumed to be the verifier who is trying to interpret
the certificate) the certificate.
o All subkeys are bound to the primary key with an [RFC4880] Subkey o All subkeys are bound to the primary key with an [RFC4880] Subkey
Binding Signature. Some subkeys also reciprocate by binding Binding Signature. Some subkeys also reciprocate by binding
themselves back to the primary key with an [RFC4880] Primary Key themselves back to the primary key with an [RFC4880] Primary Key
Binding Signature. The Primary Key Binding Signature is also Binding Signature. The Primary Key Binding Signature is also
known as a "cross-signature" or "cross-sig". known as a "cross-signature" or "cross-sig".
o A "keystore" is any collection of OpenPGP certificates. Keystores o A "keystore" is any collection of OpenPGP certificates. Keystores
typically receive mergeable updates over the course of their typically receive mergeable updates over the course of their
lifetime which might add to the set of OpenPGP certificates they lifetime which might add to the set of OpenPGP certificates they
skipping to change at page 6, line 11 skipping to change at page 6, line 14
the certificate is valid for this e-mail address before encrypting the certificate is valid for this e-mail address before encrypting
to it. Some clients may rely on specific keystores for to it. Some clients may rely on specific keystores for
certificate validation, but some keystores (e.g., [SKS]) make no certificate validation, but some keystores (e.g., [SKS]) make no
assertions whatsoever about certificate validity, and others offer assertions whatsoever about certificate validity, and others offer
only very subtle guarantees. See Section 3.4 for more details. only very subtle guarantees. See Section 3.4 for more details.
o "Certificate lookup" refers to the retrieval of a set of o "Certificate lookup" refers to the retrieval of a set of
certificates from a keystore based on the user ID or some certificates from a keystore based on the user ID or some
substring match of the user ID. See Section 3.3 for more details. substring match of the user ID. See Section 3.3 for more details.
o "Certificate update" refers to retrieval of a certificate from a o "Certificate refresh" refers to retrieval of a certificate from a
keystore based on the fingerprint of the primary key. See keystore based on the fingerprint of the primary key. See
Section 3.1 for more details. Section 3.1 for more details.
o "Certificate discovery" refers to the retrieval of a set of o "Certificate discovery" refers to the retrieval of a set of
certificates from a keystore based on the fingerprint or key ID of certificates from a keystore based on the fingerprint or key ID of
any key in the certificate. See Section 3.2 for more details. any key in the certificate. See Section 3.2 for more details.
o A "keyserver" is a particular kind of keystore, typically a means o A "keyserver" is a particular kind of keystore, typically a means
of publicly distributing OpenPGP certificates or updates to them. of publicly distributing OpenPGP certificates or updates to them.
Examples of keyserver software include [SKS] and Examples of keyserver software include [SKS] and
[MAILVELOPE-KEYSERVER]. One common HTTP interface for keyservers [MAILVELOPE-KEYSERVER]. One common HTTP interface for keyservers
is [I-D.shaw-openpgp-hkp]. is [I-D.shaw-openpgp-hkp].
o A "synchronizing keyserver" is a keyserver which gossips with o A "synchronizing keyserver" is a keyserver which gossips with
other peers, and typically acts as an append-only log. Such a other peers, and typically acts as an append-only log. Such a
keyserver is typically useful for certificate lookup, certificate keyserver is typically useful for certificate lookup, certificate
discovery, and certificate update (including revocation discovery, and certificate refresh (including revocation
information). They are typically _not_ useful for certificate information). They are typically _not_ useful for certificate
validation, since they make no assertions about whether the validation, since they make no assertions about whether the
identities in the certificates they server are accurate. As of identities in the certificates they server are accurate. As of
the writing of this document, [SKS] is the canonical synchronizing the writing of this document, [SKS] is the canonical synchronizing
keyserver implementation, though other implementations exist. keyserver implementation, though other implementations exist.
o An "e-mail validating keyserver" is a keyserver which attempts to o An "e-mail validating keyserver" is a keyserver which attempts to
verify the identity in an OpenPGP certificate's user ID by verify the identity in an OpenPGP certificate's user ID by
confirming access to the e-mail account, and possibly by confirming access to the e-mail account, and optionally by
confirming access to the secret key. Some implementations permit confirming access to the secret key. Some implementations permit
removal of a certificate by anyone who can prove access to the removal of a certificate by anyone who can prove access to the
e-mail address in question. They are useful for certificate e-mail address in question. They are useful for certificate
lookup based on e-mail address and certificate validation (by lookup based on e-mail address and certificate validation (by
users who trust the operator), but some may not be useful for users who trust the operator), but some may not be useful for
certificate update or certificate discovery, since a certificate certificate refresh or certificate discovery, since a certificate
could be simply replaced by an adversary who also has access to could be simply replaced by an adversary who also has access to
the e-mail address in question. [MAILVELOPE-KEYSERVER] is an the e-mail address in question. [MAILVELOPE-KEYSERVER] is an
example of such a keyserver. example of such a keyserver.
o A "sovereignty-respecting" keystore is one that only distributes
data associated with a given certificate that has been explicitly
approved by the primary key of that certificate. See Section 8
for more details and example strategies.
o "Cryptographic validity" refers to mathematical evidence that a o "Cryptographic validity" refers to mathematical evidence that a
signature came from the secret key associated with the public key signature came from the secret key associated with the public key
it claims to come from. Note that a certification may be it claims to come from. Note that a certification may be
cryptographically valid without the signed data being true (for cryptographically valid without the signed data being true (for
example, a given certificate with the user ID "Alice example, a given certificate with the user ID "Alice
<alice@example.org>" might not belong to the person who controls <alice@example.org>" might not belong to the person who controls
the e-mail address "alice@example.org" even though the self-sig is the e-mail address "alice@example.org" even though the self-sig is
cryptographically valid). In particular, cryptographic validity cryptographically valid). In particular, cryptographic validity
for user ID in a certificate is typically insufficient evidence for user ID in a certificate is typically insufficient evidence
for certificate validation. Also note that knowledge of the for certificate validation. Also note that knowledge of the
public key of the issuer is necessary to determine whether any public key of the issuer is necessary to determine whether any
given signature is cryptographically valid. Some keyservers given signature is cryptographically valid. Some keyservers
perform cryptographic validation in some contexts. Other perform cryptographic validation in some contexts. Other
keyservers (like [SKS]) perform no cryptographic validation keyservers (like [SKS]) perform no cryptographic validation
whatsoever. whatsoever.
o OpenPGP revocations can have "Reason for Revocation" (see o OpenPGP revocations can have "Reason for Revocation" (see
[RFC4880]), which can be either "soft" or "hard". The set of [RFC4880]), which can be either "soft" or "hard". The set of
"soft" reasons is: "Key is superseded" and "Key is retired and no "soft" reasons is: "Key is superseded" and "Key is retired and no
longer used". All other reasons (and revocations that do not longer used". All other reasons (and revocations that do not
state a reason) are "hard" revocations. See Section 14.1 for more state a reason) are "hard" revocations. See Section 12.1 for more
detail. detail.
2. Problem Statement 2. Problem Statement
OpenPGP keystores that handle submissions from the public are subject OpenPGP keystores that handle submissions from the public are subject
to a range of attacks by malicious submitters. to a range of attacks by malicious submitters.
This section describes five distinct attacks that public keystores This section describes five distinct attacks that public keystores
should consider. should consider.
The rest of the document describes some mitigations that can be used
by keystores that are concerned about these problems but want to
continue to offer some level of service for certificate lookup,
certificate update, certificate discovery, or certificate validation.
2.1. Certificate Flooding 2.1. Certificate Flooding
Many public keystores (including both the [SKS] keyserver network and Many public keystores (including both the [SKS] keyserver network and
[MAILVELOPE-KEYSERVER]) allow anyone to attach arbitrary data (in the [MAILVELOPE-KEYSERVER]) allow anyone to attach arbitrary data (in the
form of third-party certifications) to any certificate, bloating that form of third-party certifications) to any certificate, bloating that
certificate to the point of being impossible to effectively retrieve. certificate to the point of being impossible to effectively retrieve.
For example, some OpenPGP implementations simply refuse to process For example, some OpenPGP implementations simply refuse to process
certificates larger than a certain size. certificates larger than a certain size.
This kind of Denial-of-Service attack makes it possible to make This kind of Denial-of-Service attack makes it possible to make
someone else's certificate unretrievable from the keystore, someone else's certificate unretrievable from the keystore,
preventing certificate lookup, discovery, or update. In the case of preventing certificate lookup, discovery, or refresh. In the case of
a revoked certificate that has been flooded, this potentially leaves a revoked certificate that has been flooded, this potentially leaves
the client of the keystore with the compromised certificate in an the client of the keystore with the compromised certificate in an
unrevoked state locally because it was unable to fetch the revocation unrevoked state locally because it was unable to fetch the revocation
information. information.
Additionally, even without malice, OpenPGP certificates can Additionally, even without malice, OpenPGP certificates can
potentially grow without bound. potentially grow without bound.
2.2. User ID Flooding 2.2. User ID Flooding
Public keystores that are used for certificate lookup may also be Public keystores that are used for certificate lookup may also be
vulnerable to attacks that flood the space of known user IDs. In vulnerable to attacks that flood the space of known user IDs. In
particular, if the keystore accepts arbitrary certificates from the particular, if the keystore accepts arbitrary certificates from the
public and does no verification of the user IDs, then any client public and does no verification of the user IDs, then any client
searching for a given user ID may need to review and process an searching for a given user ID may need to review and process an
effectively unbounded set of maliciously-submitted certificates to effectively unbounded set of maliciously-submitted certificates to
find the non-malicious certificates they are looking for. find the non-malicious certificates they are looking for.
For example, if an attacker knows that a given system consults a For example, if an attacker knows that a given system consults a
keystore looking for certificates which match the e-mail address keystore looking for certificates which match the e-mail address
"alice@example.org", the attacker may upload hundreds or thousands of "alice@example.org", the attacker may upload thousands of
certificates containing user IDs that match that address. Even if certificates containing user IDs that match that address. Even if
those certificates would not be accepted by a client (e.g., because those certificates would not be accepted by a client (e.g., because
they were not certified by a known-good authority), the client they were not certified by a known-good authority), the client still
typically still has to wade through all of them in order to find the has to iterate through all of them in order to find the non-malicious
non-malicious certificates. certificates.
If the keystore does not offer a lookup interface at all (that is, if User ID flooding is only effective if the keystore offers a lookup
clients cannot search it by user ID), then user ID flooding is of interface at all.
less consequence.
2.3. Fingerprint Flooding 2.3. Fingerprint Flooding
A malicious actor who wants to render a certificate unavailable for A malicious actor who wants to render a certificate unavailable for
update may generate an arbitrary number of OpenPGP certificates with refresh may generate an arbitrary number of OpenPGP certificates with
the targeted primary key attached as a subkey. If they can convince the targeted primary key attached as a subkey. If they can convince
a keystore to accept all of those certificates, and the keystore a keystore to accept all of those certificates, and the keystore
returns them by subkey match during certificate update, then the returns them by subkey match during certificate refresh, then the
certificate update client will need to spend an arbitrary amount of certificate refresh client will need to spend an arbitrary amount of
bandwidth and processing power filtering out the irrelevant data, and bandwidth and processing power filtering out the irrelevant data, and
may potentially give up before discovering the certificate of may potentially give up before discovering the certificate of
interest. interest.
A malicious actor may also want to confuse a certificate discovery A malicious actor may also want to confuse a certificate discovery
request that was targeted at a particular subkey, by binding that request that was targeted at a particular subkey, by binding that
subkey to multiple bogus certificates. If these bogus certificates subkey to multiple bogus certificates. If these bogus certificates
are ingested and redistributed by the keystore, then a certificate are ingested and redistributed by the keystore, then a certificate
discovery client may receive a set of certificates that cannot be discovery client may receive a set of certificates that cannot be
adequately distinguished. adequately distinguished.
skipping to change at page 10, line 5 skipping to change at page 10, line 5
They are represented in abstract form, and are not intended to be the They are represented in abstract form, and are not intended to be the
full set of interfaces offered by any keystore, but rather a full set of interfaces offered by any keystore, but rather a
convenient way to think about the operations that make the keystore convenient way to think about the operations that make the keystore
useful for its clients. useful for its clients.
Not all keystores may offer all of these interfaces, or they may Not all keystores may offer all of these interfaces, or they may
offer them in subtly different forms, but clients will nevertheless offer them in subtly different forms, but clients will nevertheless
try to perform something like these operations with keystores that try to perform something like these operations with keystores that
they interact with. they interact with.
3.1. Certificate Update 3.1. Certificate Refresh
This is the simplest keystore operation. The client sends the This is the simplest keystore operation. The client sends the
keystore the full fingerprint of the certificate's primary key, and keystore the full fingerprint of the certificate's primary key, and
the keystore sends the client the corresponding certificate (or the keystore sends the client the corresponding certificate (or
nothing, if the keystore does not contain a certificate with a nothing, if the keystore does not contain a certificate with a
matching primary key). matching primary key).
keystore.cert_update(primary_fpr) -> certificate? keystore.cert_refresh(primary_fpr) -> certificate?
A client uses certificate update to retrieve the full details of a A client uses certificate refresh to retrieve the full details of a
certificate that it already knows about. For example, it might be certificate that it already knows about. For example, it might be
interested in updates to the certificate known to the keystore, interested in refreshs to the certificate known to the keystore,
including revocations, expiration updates, new third-party including revocations, expiration refreshs, new third-party
certifications, etc. certifications, etc.
Upon successful update, the client SHOULD merge the retrieved Upon successful refresh, the client SHOULD merge the retrieved
certificate with its local copy. certificate with its local copy.
Not all keystores offer this operation. For example, clients cannot Not all keystores offer this operation. For example, clients cannot
use WKD ([I-D.koch-openpgp-webkey-service]) or OPENPGPKEY ([RFC7929] use WKD ([I-D.koch-openpgp-webkey-service]) or OPENPGPKEY ([RFC7929])
for certificate update. for certificate refresh.
3.2. Certificate Discovery 3.2. Certificate Discovery
If a client is aware of an OpenPGP signature or certification that it If a client is aware of an OpenPGP signature or certification that it
cannot verify because it does not know the issuing certificate, it cannot verify because it does not know the issuing certificate, it
may consult a keystore to try to discover the certificate based on may consult a keystore to try to discover the certificate based on
the Issuer or Issuer Fingerprint subpacket in the signature or the Issuer or Issuer Fingerprint subpacket in the signature or
certification it is trying to validate. certification it is trying to validate.
keystore.cert_discovery(keyid|fpr) -> certificate_list keystore.cert_discovery(keyid|fpr) -> certificate_list
This is subtly different from certificate update (Section 3.1) in This is subtly different from certificate refresh (Section 3.1) in
three ways: three ways:
o it may return more than one certificate (e.g., when multiple o it may return more than one certificate (e.g., when multiple
certificates share a subkey, or when a primary key on one certificates share a subkey, or when a primary key on one
certificate is a subkey on another) certificate is a subkey on another)
o it is willing to accept searches by short key ID, not just o it is willing to accept searches by short key ID, not just
fingerprint fingerprint
o it is willing to match against a subkey, not just a primary key o it is willing to match against a subkey, not just a primary key
skipping to change at page 11, line 34 skipping to change at page 11, line 34
If a client wants to encrypt a message to a particular e-mail If a client wants to encrypt a message to a particular e-mail
address, or wants to encrypt a backup to some identity that it knows address, or wants to encrypt a backup to some identity that it knows
of but does not have a certificate for, it may consult a keystore to of but does not have a certificate for, it may consult a keystore to
discover certificates that claim that identity in their user ID discover certificates that claim that identity in their user ID
packets. Both [I-D.koch-openpgp-webkey-service] and packets. Both [I-D.koch-openpgp-webkey-service] and
[I-D.shaw-openpgp-hkp] offer certificate lookup mechanisms. [I-D.shaw-openpgp-hkp] offer certificate lookup mechanisms.
[RFC4880] User IDs are constrained only in that they are a UTF-8 [RFC4880] User IDs are constrained only in that they are a UTF-8
string, but some conventions govern their practical use. See string, but some conventions govern their practical use. See
Section 14.2 for more discussion of some common conventions around Section 12.2 for more discussion of some common conventions around
user ID structure. user ID structure.
Note that lookup does not necessarily imply user ID or certificate Note that lookup does not necessarily imply user ID or certificate
validation. It is entirely possible for a keystore to return a validation. It is entirely possible for a keystore to return a
certificate during lookup that the client cannot validate. certificate during lookup that the client cannot validate.
Abuse-resistant keystores that offer a lookup interface SHOULD Abuse-resistant keystores that offer a lookup interface SHOULD
distinguish interfaces that perform full-string-match lookup from distinguish interfaces that perform full-string-match lookup from
interfaces that perform e-mail address based lookup. interfaces that perform e-mail address based lookup.
skipping to change at page 12, line 19 skipping to change at page 12, line 19
3.3.2. E-mail Address Lookup 3.3.2. E-mail Address Lookup
However, some common use cases look for specific patterns in the user However, some common use cases look for specific patterns in the user
ID rather than the entire user ID. Most useful to many existing ID rather than the entire user ID. Most useful to many existing
OpenPGP clients is a lookup by e-mail address. OpenPGP clients is a lookup by e-mail address.
keystore.cert_lookup(addr) -> certificate_list keystore.cert_lookup(addr) -> certificate_list
For certificates with a user ID that matches the structure of an For certificates with a user ID that matches the structure of an
[RFC5322] "name-addr" or "addr-spec", a keystore SHOULD extract the [RFC5322] "name-addr" or "addr-spec", a keystore SHOULD extract the
"addr-spec" from the user ID, canonicalize it (see Section 14.3), and "addr-spec" from the user ID, canonicalize it (see Section 12.3), and
compare it to the canonicalized form of of the "addr" query compare it to the canonicalized form of of the "addr" query
parameter. parameter.
3.3.3. Other Lookup Mechanisms 3.3.3. Other Lookup Mechanisms
Some keystores offer other forms of substring or regular expression Some keystores offer other forms of substring or regular expression
matching against the stored user IDs. These other forms of lookup matching against the stored user IDs. These other forms of lookup
may be useful in some contexts (e.g., Section 13.7), but they may may be useful in some contexts (e.g., Section 11.7), but they may
also represent privacy concerns (e.g., Section 16.1), and they may also represent privacy concerns (e.g., Section 14.1), and they may
impose additional computational or indexing burdens on the keystore. impose additional computational or indexing burdens on the keystore.
3.4. Certificate Validation 3.4. Certificate Validation
An OpenPGP client may assess certificate and user ID validity based An OpenPGP client may assess certificate and user ID validity based
on many factors, some of which are directly contained in the on many factors, some of which are directly contained in the
certificate itself (e.g., third-party certifications), and some of certificate itself (e.g., third-party certifications), and some of
which are based on the context known to the client, including: which are based on the context known to the client, including:
o Whether it has seen e-mails from that address signed by that o Whether it has seen e-mails from that address signed by that
skipping to change at page 13, line 35 skipping to change at page 13, line 35
should only be interpreted as a claim of validity about any user ID should only be interpreted as a claim of validity about any user ID
which matches the e-mail address by which the certificate was looked which matches the e-mail address by which the certificate was looked
up, with no claims made about any "display-name" portions, or about up, with no claims made about any "display-name" portions, or about
any user ID that doesn't match the queried e-mail address at all. any user ID that doesn't match the queried e-mail address at all.
A keystore that offers some sort of validation interface may also A keystore that offers some sort of validation interface may also
change its opinion about the validity of a given certificate or user change its opinion about the validity of a given certificate or user
ID over time; the interface described above only allows the client to ID over time; the interface described above only allows the client to
ask about the keystore's current opinion, but a more complex ask about the keystore's current opinion, but a more complex
interface might be capable of describing the keystore's assertion interface might be capable of describing the keystore's assertion
over time. See also Section 13.5. over time. See also Section 11.5.
An abuse-resistant keystore that clients rely on for any part of An abuse-resistant keystore that clients rely on for any part of
their certificate validation process SHOULD offer a distinct their certificate validation process SHOULD offer a distinct
interface for making assertions about certificate and user ID interface for making assertions about certificate and user ID
validity to help clients avoid some of the subtleties involved with validity to help clients avoid some of the subtleties involved with
inference based on presence described above. inference based on presence described above.
Note that the certificate validation operation as described above has Note that the certificate validation operation as described above has
a boolean response. While a "true" response indicates that keystore a boolean response. While a "true" response indicates that keystore
believes the user ID or e-mail address is acceptable for use with the believes the user ID or e-mail address is acceptable for use with the
certificate referred to by the public key fingerprint, a "false" certificate referred to by the public key fingerprint, a "false"
response doesn't necessarily mean that the keystore actively thinks response doesn't necessarily mean that the keystore actively thinks
that the certificate is actively bad, or must not be used for the that the certificate is actively bad, or must not be used for the
referenced identity. Rather, "false" is the default state: no referenced identity. Rather, "false" is the default state: no
opinion is expressed by the keystore, and the client is left to make opinion is expressed by the keystore, and the client is left to make
their own inference about validity based on other factors. A their own inference about validity based on other factors. A
keystore MAY offer a more nuanced validity interface; if it does, it keystore MAY offer a more nuanced validity interface; if it does, it
SHOULD explicitly document the semantics of the different response SHOULD explicitly document the semantics of the different response
types so that clients can make appropriate judgement. types so that clients can make appropriate judgment.
3.5. Certificate Submission 3.5. Certificate Submission
Different keystores have different ways to submit a certificate for Different keystores have different ways to submit a certificate for
consideration for ingestion, including: consideration for ingestion, including:
o a simple upload of a certificate via http o a simple upload of a certificate via HTTP
o round-trip e-mail verification o round-trip e-mail verification
o proof of presence in some other service o proof of presence in some other service
o vouching, or other forms of multi-party attestation o vouching, or other forms of multi-party attestation
Because these schemes vary so widely, this document does not attempt Because these schemes vary so widely, this document does not attempt
to describe the keystore certificate submission process in detail. to describe the keystore certificate submission process in detail.
However, guidance can be found for implementations that generate, However, guidance can be found for implementations that generate,
manage, and submit certificates in Section 12. manage, and submit certificates in Section 10.
4. Simple Mitigations 4. Simple Mitigations
These steps can be taken by any keystore that wants to avoid These steps can be taken by any keystore that wants to avoid
obviously malicious abuse. They can be implemented on receipt of any obviously malicious abuse. They can be implemented on receipt of any
new packet, and are based strictly on the structure of the packet new packet, and are based strictly on the structure of the packet
itself. itself.
4.1. Decline Large Packets 4.1. Decline Large Packets
skipping to change at page 15, line 13 skipping to change at page 15, line 13
packets larger than 65536 octets. packets larger than 65536 octets.
4.2. Enforce Strict User IDs 4.2. Enforce Strict User IDs
[RFC4880] indicates that User IDs are expected to be UTF-8 strings. [RFC4880] indicates that User IDs are expected to be UTF-8 strings.
An abuse-resistant keystore MUST reject any user ID that is not valid An abuse-resistant keystore MUST reject any user ID that is not valid
UTF-8. UTF-8.
Some abuse-resistant keystores MAY only accept User IDs that meet Some abuse-resistant keystores MAY only accept User IDs that meet
even stricter conventions, such as an [RFC5322] "name-addr" or "addr- even stricter conventions, such as an [RFC5322] "name-addr" or "addr-
spec", or a URL like "ssh://host.example.org" (see Section 14.2). spec", or a URL like "ssh://host.example.org" (see Section 12.2).
As simple text strings, User IDs don't need to be nearly as long as As simple text strings, User IDs don't need to be nearly as long as
any other packets. An abuse-resistant keystore SHOULD reject any any other packets. An abuse-resistant keystore SHOULD reject any
user ID packet larger than 1024 octets. user ID packet larger than 1024 octets.
4.3. Scoped User IDs 4.3. Scoped User IDs
Some abuse-resistant keystores may restrict themselves to publishing Some abuse-resistant keystores may restrict themselves to publishing
only certificates with User IDs that match a specific pattern. For only certificates with User IDs that match a specific pattern. For
example, [RFC7929] encourages publication in the DNS of only example, [RFC7929] encourages publication in the DNS of only
skipping to change at page 16, line 12 skipping to change at page 16, line 12
cryptographically-validating abuse-resistant keystore SHOULD be cryptographically-validating abuse-resistant keystore SHOULD be
willing to redistribute a valid cross-sig as an unhashed subpacket. willing to redistribute a valid cross-sig as an unhashed subpacket.
The redistributed unhashed cross-sig itself should be stripped of all The redistributed unhashed cross-sig itself should be stripped of all
unhashed subpackets. unhashed subpackets.
4.4.3. First-party Attestations 4.4.3. First-party Attestations
Some third-party certifications are attested to by the certificate Some third-party certifications are attested to by the certificate
primary key itself in an unhashed subpacket, as described in primary key itself in an unhashed subpacket, as described in
Section 10. A cryptographically-validating abuse-resistant keystore Section 8.3. A cryptographically-validating abuse-resistant keystore
SHOULD be willing to redistribute a valid first-party attestation as SHOULD be willing to redistribute a valid first-party attestation as
an unhashed subpacket. an unhashed subpacket.
The redistributed first-party attestation itself should be stripped The redistributed first-party attestation itself should be stripped
of all unhashed subpackets. of all unhashed subpackets.
4.5. Decline User Attributes 4.5. Decline User Attributes
Due to size concerns, some abuse-resistant keystores MAY choose to Due to size concerns, some abuse-resistant keystores MAY choose to
ignore user attribute packets entirely, as well as any certifications ignore user attribute packets entirely, as well as any certifications
skipping to change at page 17, line 14 skipping to change at page 17, line 14
notations, or certain combinations of subpackets. This can help to notations, or certain combinations of subpackets. This can help to
minimize the amount of room for garbage data uploads. minimize the amount of room for garbage data uploads.
Any abuse-resistant keystore that adopts such a strict posture should Any abuse-resistant keystore that adopts such a strict posture should
clearly document what its expected certificate profile is, and should clearly document what its expected certificate profile is, and should
have a plan for how to extend the profile if new types of have a plan for how to extend the profile if new types of
certification appear that it wants to be able to distribute. certification appear that it wants to be able to distribute.
Note that if the profile is ever restricted (rather than extended), Note that if the profile is ever restricted (rather than extended),
and the restriction is applied to the material already present, such and the restriction is applied to the material already present, such
a keystore is no longer append-only (please see Section 7). a keystore is no longer append-only (see Section 7).
4.9. Accept Only Certificates Issued by Designated Authorities 4.9. Accept Only Certificates Issued by Designated Authorities
An abuse-resistant keystore capable of cryptographic validation MAY An abuse-resistant keystore capable of cryptographic validation MAY
retain a list of designated authorities, typically in the form of a retain a list of designated authorities, typically in the form of a
set of known public keys. Upon receipt of a new OpenPGP certificate, set of known public keys. Upon receipt of a new OpenPGP certificate,
the keystore can decide whether to accept or decline each user ID of the keystore can decide whether to accept or decline each user ID of
the certificate based whether that user ID has a certification that the certificate based whether that user ID has a certification that
was issued by one or more of the designated authorities. was issued by one or more of the designated authorities.
skipping to change at page 17, line 41 skipping to change at page 17, line 41
The operator of such a keystore SHOULD have a clear policy about its The operator of such a keystore SHOULD have a clear policy about its
set of designated authorities. set of designated authorities.
Given the ambiguities about expiration and revocation, such a Given the ambiguities about expiration and revocation, such a
keyserver SHOULD ignore expiration and revocation of authority keyserver SHOULD ignore expiration and revocation of authority
certifications, and simply accept and retain as long as the certifications, and simply accept and retain as long as the
cryptographic signature is valid. cryptographic signature is valid.
Note that if any key is removed from the set of designated Note that if any key is removed from the set of designated
authorities, and that change is applied to the existing keystore, authorities, and that change is applied to the existing keystore,
such a keystore may no longer be append-only (please see Section 7). such a keystore may no longer be append-only (see Section 7).
4.10. Decline Packets by Blocklist 4.10. Decline Packets by Blocklist
The maintainer of the keystore may keep a specific list of "known- The maintainer of the keystore may keep a specific list of "known-
bad" material, and decline to accept or redistribute items matching bad" material, and decline to accept or redistribute items matching
that blocklist. The material so identified could be anything, but that blocklist. The material so identified could be anything, but
most usefully, specific public keys or User IDs could be blocked. most usefully, specific public keys or User IDs could be blocked.
Note that if a blocklist grows to include an element already present Note that if a blocklist grows to include an element already present
in the keystore, it will no longer be append-only (please see in the keystore, it will no longer be append-only (see Section 7).
Section 7).
Some keystores may choose to apply a blocklist only at retrieval time Some keystores may choose to apply a blocklist only at retrieval time
and not apply it at ingestion time. This allows the keystore to be and not apply it at ingestion time. This allows the keystore to be
append-only, and permits synchronization between keystores that don't append-only, and permits synchronization between keystores that don't
share a blocklist, and somewhat reduces the attacker's incentive for share a blocklist, and somewhat reduces the attacker's incentive for
flooding the keystore (see Section 5 for more discussion). flooding the keystore (see Section 5 for more discussion).
Note that development and maintenance of a blocklist is not without Note that development and maintenance of a blocklist is not without
its own potentials for abuse. For one thing, the blocklist may its own potentials for abuse. For one thing, the blocklist may
itself grow without bound. Additionally, a blocklist may be socially itself grow without bound. Additionally, a blocklist may be socially
skipping to change at page 18, line 33 skipping to change at page 18, line 29
be an "attractive nuisance," drawing the interest of would-be censors be an "attractive nuisance," drawing the interest of would-be censors
or other attacker interested in controlling the ecosystem reliant on or other attacker interested in controlling the ecosystem reliant on
the keystore in question. the keystore in question.
5. Retrieval-time Mitigations 5. Retrieval-time Mitigations
Most of the abuse mitigations described in this document are Most of the abuse mitigations described in this document are
described as being applied at certificate ingestion time. It's also described as being applied at certificate ingestion time. It's also
possible to apply the same mitigations when a certificate is possible to apply the same mitigations when a certificate is
retrieved from the keystore (that is, during certificate lookup, retrieved from the keystore (that is, during certificate lookup,
update, or discovery). Applying an abuse mitigation at retrieval refresh, or discovery). Applying an abuse mitigation at retrieval
time may help a client defend against a user ID flooding time may help a client defend against a user ID flooding
(Section 2.2), certificate flooding (Section 2.1), or fingerprint (Section 2.2), certificate flooding (Section 2.1), or fingerprint
flooding (Section 2.3) attack. It may also help a keystore limit its flooding (Section 2.3) attack. It may also help a keystore limit its
liability for redistributing toxic data (Section 2.5). However, only liability for redistributing toxic data (Section 2.5). However, only
mitigations applied at ingestion time are able to mitigate keystore mitigations applied at ingestion time are able to mitigate keystore
flooding attacks (Section 2.4). flooding attacks (Section 2.4).
Some mitigations (like the non-append-only mitigations described in Some mitigations (like the non-append-only mitigations described in
Section 7) may be applied as filters at retrieval time, while still Section 7) may be applied as filters at retrieval time, while still
allowing access to the (potentially much larger) unfiltered dataset allowing access to the (potentially much larger) unfiltered dataset
associated given certificate or user ID via a distinct interface. associated given certificate or user ID via a distinct interface.
The rest of this section documents specific mitigations that are only The rest of this section documents specific mitigations that are only
relevant at retrieval time (certificate discovery, lookup, or relevant at retrieval time (certificate discovery, lookup, or
update). refresh).
5.1. Redacting User IDs 5.1. Redacting User IDs
Some abuse-resistant keystores may accept and store user IDs but Some abuse-resistant keystores may accept and store user IDs but
decline to redistribute some or all of them, while still distributing decline to redistribute some or all of them, while still distributing
the certifications that cover those redacted user IDs. This draft the certifications that cover those redacted user IDs. This draft
refers to such a keystore as a "user ID redacting" keystore. refers to such a keystore as a "user ID redacting" keystore.
The certificates distributed by such a keystore are technically The certificates distributed by such a keystore are technically
invalid [RFC4880] "transferable public keys", because they lack a invalid [RFC4880] "transferable public keys", because they lack a
user ID packet, and the distributed certifications cannot be user ID packet, and the distributed certifications cannot be
cryptographically validated independently. However, an OpenPGP cryptographically validated independently. However, an OpenPGP
implementation that already knows the user IDs associated with a implementation that already knows the user IDs associated with a
given primary key will be capable of associating each certification given primary key will be capable of associating each certification
with the correct user ID by trial signature verification. with the correct user ID by trial signature verification.
5.1.1. Certificate Update with Redacted User IDs 5.1.1. Certificate Refresh with Redacted User IDs
A user ID redacting keystore is useful for certificate update by a A user ID redacting keystore is useful for certificate refresh by a
client that already knows the user ID it expects to see associated client that already knows the user ID it expects to see associated
with the certificate. For example, a client that knows a given with the certificate. For example, a client that knows a given
certificate currently has two specific user IDs could access the certificate currently has two specific user IDs could access the
keystore to learn that one of the user IDs has been revoked, without keystore to learn that one of the user IDs has been revoked, without
any other client learning the user IDs directly from the keystore. any other client learning the user IDs directly from the keystore.
5.1.2. Certificate Discovery with Redacted User IDs 5.1.2. Certificate Discovery with Redacted User IDs
A user ID redacting keystore is somewhat less useful for clients A user ID redacting keystore is somewhat less useful for clients
doing certificate discovery. Consider the circumstance of receiving doing certificate discovery. Consider the circumstance of receiving
skipping to change at page 20, line 12 skipping to change at page 20, line 5
o The resulting string should be an [RFC5322] "name-addr" or "addr- o The resulting string should be an [RFC5322] "name-addr" or "addr-
spec". spec".
o If it is a "name-addr", convert the UTF-8 string into an OpenPGP o If it is a "name-addr", convert the UTF-8 string into an OpenPGP
user ID and check whether the certification validates, terminating user ID and check whether the certification validates, terminating
on success. on success.
* If the test fails, extract the "addr-spec" from the "name-addr" * If the test fails, extract the "addr-spec" from the "name-addr"
and continue. and continue.
o Canonicalize the "addr-spec" according to Section 14.3, and check o Canonicalize the "addr-spec" according to Section 12.3, and check
whether the certification validates, terminating on success. whether the certification validates, terminating on success.
o If it doesn't validate wrap the canonicalized "addr-spec" in o If it doesn't validate wrap the canonicalized "addr-spec" in
angle-brackets ("<" and ">") and test the resulting minimalist angle-brackets ("<" and ">") and test the resulting minimalist
"name-addr" against the certification, terminating on success. "name-addr" against the certification, terminating on success.
o If all of the above fails, synthesis has failed. o If all of the above fails, synthesis has failed.
5.1.3. Certificate Lookup with Redacted User IDs 5.1.3. Certificate Lookup with Redacted User IDs
skipping to change at page 20, line 38 skipping to change at page 20, line 31
client that knows the full user ID they are searching for will be client that knows the full user ID they are searching for will be
able to verify the returned certifications. able to verify the returned certifications.
Certificate lookup from a user ID redacting keystore works better for Certificate lookup from a user ID redacting keystore works better for
certificate lookup by exact user ID match than it does for substring certificate lookup by exact user ID match than it does for substring
match, because a client that retrieves a certificate via a substring match, because a client that retrieves a certificate via a substring
match may not be able to reconstruct the redacted user ID. match may not be able to reconstruct the redacted user ID.
However, without some additional restrictions on which certifications However, without some additional restrictions on which certifications
are redistributed (whether the user ID is redacted or not), are redistributed (whether the user ID is redacted or not),
certificate lookup can be flooded (see Section 15.1). certificate lookup can be flooded (see Section 13.1).
5.1.4. Hinting Redacted User IDs 5.1.4. Hinting Redacted User IDs
To ensure that the distributed certificate is at least structurally a To ensure that the distributed certificate is at least structurally a
valid [RFC4880] transferable public key, a user ID redacting keystore valid [RFC4880] transferable public key, a user ID redacting keystore
MAY distribute an empty user ID (an OpenPGP packet of tag 13 whose MAY distribute an empty user ID (an OpenPGP packet of tag 13 whose
contents are a zero-octet string) in place of the omitted user ID. contents are a zero-octet string) in place of the omitted user ID.
This two-octet replacement user ID packet ("\xb4\x00") is called the This two-octet replacement user ID packet ("\xb4\x00") is called the
"unstated user ID". "unstated user ID".
To facilitate clients that match certifications with specific user To facilitate clients that match certifications with specific user
IDs, a user ID redacting keystore MAY insert a non-hashed notation IDs, a user ID redacting keystore MAY insert a non-hashed notation
subpacket into the certification. The notation will have a name of subpacket into the certification. The notation will have a name of
"uidhash", with 0x80 ("human-readable") flag unset. The value of "uidhash", with 0x80 ("human-readable") flag unset. The value of
such a notation MUST be 32 octets long, and contains the SHA-256 such a notation MUST be 32 octets long, and contains the SHA-256
cryptographic digest of the UTF-8 string of the redacted user ID. cryptographic digest of the UTF-8 string of the redacted user ID.
A certificate update client which receives such a certification after A certificate refresh client which receives such a certification
the "unstated user ID" SHOULD compute the SHA-256 digest of all user after the "unstated user ID" SHOULD compute the SHA-256 digest of all
IDs it knows about on the certificate, and compare the result with user IDs it knows about on the certificate, and compare the result
the contents of the "uidhash" notation to decide which user ID to try with the contents of the "uidhash" notation to decide which user ID
to validate the certification against. to try to validate the certification against.
5.1.5. User ID Recovery by Client Brute Force 5.1.5. User ID Recovery by Client Brute Force
User ID redaction is at best an imperfect process. Even if a User ID redaction is at best an imperfect process. Even if a
keystore redacts a User ID, if it ships a certification over that keystore redacts a User ID, if it ships a certification over that
user ID, an interested client can guess user IDs until it finds one user ID, an interested client can guess user IDs until it finds one
that causes the signature to verify. This is even easier when the that causes the signature to verify. This is even easier when the
space of legitimate user IDs is relatively small, such as the set of space of legitimate user IDs is relatively small, such as the set of
commonly-used hostnames commonly-used hostnames.
5.2. Primary-key Only Certificate Update 5.2. Primary-key Only Certificate Refresh
Abuse-resistant keystores can defend against a fingerprint flooding Abuse-resistant keystores can defend against a fingerprint flooding
Section 2.3 attack during certificate update by implementing a Section 2.3 attack during certificate refresh by implementing a
narrowly-constrained certificate update interface. narrowly-constrained certificate refresh interface.
Such a keystore MUST accept only a full fingerprint as the search Such a keystore MUST accept only a full fingerprint as the search
parameter from the certificate update client, and it MUST return at parameter from the certificate refresh client, and it MUST return at
most a single certificate whose primary key matches the requested most a single certificate whose primary key matches the requested
fingerprint. It MUST NOT return more than one certificate, and it fingerprint. It MUST NOT return more than one certificate, and it
MUST NOT return any certificate whose primary key does not match the MUST NOT return any certificate whose primary key does not match the
fingerprint. In particular, it MUST NOT return certificates where fingerprint. In particular, it MUST NOT return certificates where
only the subkey fingerprint matches. only the subkey fingerprint matches.
Note that [I-D.shaw-openpgp-hkp] does not offer the primitive Note that [I-D.shaw-openpgp-hkp] does not offer the primitive
described in Section 3.1 exactly. In that specification, the set of described in Section 3.1 exactly. In that specification, the set of
keys returned by a "get" operation with a "search" parameter that keys returned by a "get" operation with a "search" parameter that
appears to be a full fingerprint is ambiguous. Some popular appears to be a full fingerprint is ambiguous. Some popular
skipping to change at page 23, line 5 skipping to change at page 22, line 46
6.1. Accept Only Cryptographically-verifiable Certifications 6.1. Accept Only Cryptographically-verifiable Certifications
An abuse-resistant keystore that is capable of doing cryptographic An abuse-resistant keystore that is capable of doing cryptographic
validation MAY decide to reject certifications that it cannot validation MAY decide to reject certifications that it cannot
cryptographically validate. cryptographically validate.
This may mean that the keystore rejects some packets while it is This may mean that the keystore rejects some packets while it is
unaware of the public key of the issuer of the packet. unaware of the public key of the issuer of the packet.
As long as the keystore implements the verification algorithm, Any
self-signature should always be cryptographically-verifiable, since
the public key of the issuer is already present in the certificate
under consideration.
6.2. Accept Only Certificates Issued by Known Certificates 6.2. Accept Only Certificates Issued by Known Certificates
This is an extension of Section 4.9, but where the set of authorities This is an extension of Section 4.9, but where the set of authorities
is just the set of certificates already known to the keystore. An is just the set of certificates already known to the keystore. An
abuse-resistant keystore that adopts this strategy is effectively abuse-resistant keystore that adopts this strategy is effectively
only crawling the reachable graph of OpenPGP certificates from some only crawling the reachable graph of OpenPGP certificates from some
starting core. starting core.
A keystore adopting the mitigation SHOULD have a clear documentation A keystore adopting the mitigation SHOULD have a clear documentation
of the core of initial certificates it starts with, as this is of the core of initial certificates it starts with, as this is
skipping to change at page 23, line 28 skipping to change at page 23, line 28
key that is associated with a primary key of a certificate already key that is associated with a primary key of a certificate already
present in the keystore. Such a compromise permits an attacker to present in the keystore. Such a compromise permits an attacker to
flood the rest of the network. In the event that such a compromised flood the rest of the network. In the event that such a compromised
key is identified, it might be placed on a blocklist (see key is identified, it might be placed on a blocklist (see
Section 4.10). In particular, if a public key is added to a Section 4.10). In particular, if a public key is added to a
blocklist for a keystore implementing this mitigation, and it is blocklist for a keystore implementing this mitigation, and it is
removed from the keystore, then all certificates that were only removed from the keystore, then all certificates that were only
"reachable" from the blocklisted certificate should also be "reachable" from the blocklisted certificate should also be
simultaneously removed. simultaneously removed.
FIXME: There are complexities associated with this strategy when
certificates expire or are revoked. If expiration or revocation
cause some certificates to become "unreachable", what should such a
keystore do?
6.3. Rate-limit Submissions by IP Address 6.3. Rate-limit Submissions by IP Address
Some OpenPGP keystores accept material from the general public over Some OpenPGP keystores accept material from the general public over
the Internet. If an abuse-resistant keystore observes a flood of the Internet. If an abuse-resistant keystore observes a flood of
material submitted to the keystore from a given Internet address, it material submitted to the keystore from a given Internet address, it
MAY choose to throttle submissions from that address. When receiving MAY choose to throttle submissions from that address. When receiving
submissions over IPv6, such a keystore MAY choose to throttle entire submissions over IPv6, such a keystore MAY choose to throttle entire
nearby subnets, as a malicious IPv6 host is more likely to have nearby subnets, as a malicious IPv6 host is more likely to have
multiple addresses. multiple addresses.
skipping to change at page 24, line 12 skipping to change at page 24, line 19
[DEBIAN-KEYRING] adjudicates the contents of the "Debian keyring" [DEBIAN-KEYRING] adjudicates the contents of the "Debian keyring"
keystore based on organizational procedure and manual inspection. keystore based on organizational procedure and manual inspection.
6.5. Accept Certificates by E-mail Validation 6.5. Accept Certificates by E-mail Validation
Some keystores resist abuse by declining any certificate until the Some keystores resist abuse by declining any certificate until the
user IDs have been verified by e-mail. When these "e-mail user IDs have been verified by e-mail. When these "e-mail
validating" keystores review a new certificate that has a user ID validating" keystores review a new certificate that has a user ID
with an e-mail address in it, they send an e-mail to the associated with an e-mail address in it, they send an e-mail to the associated
address with a confirmation mechanism (e.g., a high-entropy HTTPS URL address with a confirmation mechanism (e.g., a high-entropy HTTPS URL
link) in it. In some cases, the e-mail itself is encrypted to an link) in it. The e-mail itself MAY be encrypted to an encryption-
encryption-capable key found in the proposed certificate. If the capable key found in the proposed certificate. If the keyholder
keyholder triggers the confirmation mechanism, then the keystore triggers the confirmation mechanism, then the keystore accepts the
accepts the certificate. certificate.
Some e-mail validating keystores MAY choose to distribute Some e-mail validating keystores MAY choose to distribute
certifications over all user IDs for any given certificate, but will certifications over all user IDs for any given certificate, but will
redact (see Section 5.1) those user IDs that have not been e-mail redact (see Section 5.1) those user IDs that have not been e-mail
validated. validated.
[PGP-GLOBAL-DIRECTORY] describes some concerns held by a keystore [PGP-GLOBAL-DIRECTORY] describes some concerns held by a keystore
operator using this approach. [MAILVELOPE-KEYSERVER] is another operator using this approach. [MAILVELOPE-KEYSERVER] is another
example. example.
7. Non-append-only mitigations 7. Non-append-only mitigations
The following mitigations may cause some previously-retained packets The following mitigations may cause some previously-retained packets
to be dropped after the keystore receives new information, or as time to be dropped after the keystore receives new information, or as time
passes. This is entirely reasonable for some keystores, but it may passes. This is entirely reasonable for some keystores, but it may
be surprising for any keystore that expects to be append-only (for be surprising for clients of a keystore that expect the keystore to
example, some keyserver synchronization techniques may expect this be append-only (for example, some keyserver synchronization
property to hold). techniques may expect this property to hold).
Furthermore, keystores that drop old data (e.g., superseded Furthermore, keystores that drop old data (e.g., superseded
certifications) may make it difficult or impossible for their users certifications) may make it difficult or impossible for their users
to reason about the validity of signatures that were made in the to reason about the validity of signatures that were made in the
past. See Section 13.5 for more considerations. past. See Section 11.5 for more considerations.
Note also that many of these mitigations depend on cryptographic Note also that many of these mitigations depend on cryptographic
validation, so they're typically contextual as well. validation, so they're typically contextual as well.
A keystore that needs to be append-only, or which cannot perform A keystore that needs to be append-only, or which cannot perform
cryptographic validation MAY omit these mitigations. Alternately, a cryptographic validation MAY omit these mitigations. Alternately, a
keystore may omit these mitigations at certificate ingestion time, keystore may omit these mitigations at certificate ingestion time,
but apply these mitigations at retrieval time (during certificate but apply these mitigations at retrieval time (during certificate
update, discovery, or lookup), and offer a more verbose (non- refresh, discovery, or lookup), and offer a more verbose (non-
mitigated) interface for auditors, as described in Section 5. mitigated) interface for auditors, as described in Section 5.
Note that [GnuPG] anticipates some of these suggestions with its Note that [GnuPG] anticipates some of these suggestions with its
"clean" subcommand, which is documented as: "clean" subcommand, which is documented as:
Compact (by removing all signatures except the selfsig) Compact (by removing all signatures except the selfsig)
any user ID that is no longer usable (e.g. revoked, or any user ID that is no longer usable (e.g. revoked, or
expired). Then, remove any signatures that are not usable expired). Then, remove any signatures that are not usable
by the trust calculations. Specifically, this removes by the trust calculations. Specifically, this removes
any signature that does not validate, any signature that any signature that does not validate, any signature that
skipping to change at page 26, line 23 skipping to change at page 26, line 30
signature, an abuse-resistant keystore SHOULD drop all the rest of signature, an abuse-resistant keystore SHOULD drop all the rest of
the associated data (user IDs, user attributes, and subkeys, and all the associated data (user IDs, user attributes, and subkeys, and all
attendant certifications and subkey signatures). This defends attendant certifications and subkey signatures). This defends
against an adversary who compromises a primary key and tries to flood against an adversary who compromises a primary key and tries to flood
the certificate to hide the revocation. the certificate to hide the revocation.
Note that the direct key revocation signature MUST NOT be dropped. Note that the direct key revocation signature MUST NOT be dropped.
In the event that an abuse-resistant keystore is flooded with direct In the event that an abuse-resistant keystore is flooded with direct
key revocation signatures, it should retain the hardest, earliest key revocation signatures, it should retain the hardest, earliest
revocation (see also Section 14.1). revocation (see also Section 12.1).
In particular, if any of the direct key revocation signatures is a In particular, if any of the direct key revocation signatures is a
"hard" revocation, the abuse-resistant keystore SHOULD retain the "hard" revocation, the abuse-resistant keystore SHOULD retain the
earliest such revocation signature (by signature creation date). earliest such revocation signature (by signature creation date).
Otherwise, the abuse-resistant keystore SHOULD retain the earliest Otherwise, the abuse-resistant keystore SHOULD retain the earliest
"soft" direct key revocation signature it has seen. "soft" direct key revocation signature it has seen.
If either of the above date comparisons results in a tie between two If either of the above date comparisons results in a tie between two
revocation signatures of the same "hardness", an abuse-resistant revocation signatures of the same "hardness", an abuse-resistant
skipping to change at page 27, line 14 skipping to change at page 27, line 19
o cap the packet's expiration to the system's implicit expiration o cap the packet's expiration to the system's implicit expiration
date, or date, or
o accept the explicit expiration date. o accept the explicit expiration date.
Warning: Any implementation of this idea is pretty radical, and it's Warning: Any implementation of this idea is pretty radical, and it's
not clear what it would do to an ecosystem that depends on such a not clear what it would do to an ecosystem that depends on such a
keystore. It probably needs more thinking. keystore. It probably needs more thinking.
8. Updates-only Keystores 8. Primary Key Sovereignty
In addition to the mitigations above, some keystores may resist abuse A keystore can defend against malicious external flooding by treating
by declining to accept any user IDs or certifications whatsoever. the "first party" of each certificate as "sovereign" over that
certificate. This means in practice that no part of the certificate
will redistributed without explicit permission from the primary key.
We call a keystore that aims to respect primary key sovereignty a
"sovereignty-respecting" keystore.
[RFC4880] defines "Key Server Preferences" with a "No-modify" bit.
That bit has never been respected by any keyserver implementation
that the author is aware of. A sovereignty-respecting keystore
effectively treats that bit as always set, whether it is present in
any part of the certificate or not.
A sovereignty-respecting abuse-resistant keystore can apply other
constraints in addition to primary-key sovereignty, of course, for
reasons as diverse as performance concerns, storage capacity, legal
regulation, cryptographic algorithm support, or project policy. It
will not redistribute anything that has not been explicitly approved
by the primary key, but that does not mean it has to redistribute
everything that has been explicitly approved by the primary key.
The remaining subsections of Section 8 describe some sensible
strategies for a sovereignty-respecting keystore.
8.1. Refresh-only Keystores
Some soveriegnty-respecting keystores may resist abuse by declining
to accept any user IDs or certifications whatsoever.
Such a keystore MUST be capable of cryptographic validation. It Such a keystore MUST be capable of cryptographic validation. It
accepts primary key packets, cryptographically-valid direct-key accepts primary key packets, cryptographically-valid direct-key
signatures from a primary key over itself, subkeys and their signatures from a primary key over itself, subkeys and their
cryptographically-validated binding signatures (and cross-sigs, where cryptographically-validated binding signatures (and cross-sigs, where
necessary). necessary).
A client of an updates-only keystore cannot possibly use the keystore A client of a refresh-only keystore cannot possibly use the keystore
for certificate lookup, because there are no user IDs to match. And for certificate lookup, because there are no user IDs to match. And
it is not particularly useful for certificate discovery, because the it is not particularly useful for certificate discovery, because the
returned certificate would have no identity information. However, returned certificate would have no identity information. However,
such a keystore can be used for certificate update, as it's possible such a keystore can be used for certificate refresh, as it's possible
to ship revocations (which are direct key signatures), new subkeys, to ship revocations (which are direct key signatures), new subkeys,
updates to subkey expiration, subkey revocation, and direct key updates to subkey expiration, subkey revocation, and direct key
signature-based certificate expiration updates. signature-based certificate expiration updates.
Note that many popular OpenPGP implementations do not implement Note that many popular OpenPGP implementations do not implement
direct primary key expiration mechanisms, relying instead on user ID direct primary key expiration mechanisms, relying instead on user ID
expirations. These user ID expiration dates or other metadata expirations. These user ID expiration dates or other metadata
associated with a self-certification will not be distributed by an associated with a self-certification will not be distributed by an
updates-only keystore. refresh-only keystore.
Certificates shipped by an updates-only keystore are technically Certificates shipped by an refresh-only keystore are technically
invalid [RFC4880] "transferable public keys," because they lack a invalid [RFC4880] "transferable public keys," because they lack a
user ID packet. However many OpenPGP implementations will accept user ID packet. However many OpenPGP implementations will accept
such a certificate if they already know of a user ID for the such a certificate if they already know of a user ID for the
certificate, because the composite certificate resulting from a merge certificate, because the composite certificate resulting from a merge
will be a standards-compliant transferable public key. will be a standards-compliant transferable public key.
9. First-party-only Keystores 8.2. First-party-only Keystores
Slightly more permissive than the updates-only keystore described in Slightly more permissive than the refresh-only keystore described in
Section 8 is a keystore that also permits user IDs and their self- Section 8.1 is a sovereignty-respecting keystore that also permits
sigs. user IDs and their self-sigs.
A first-party-only keystore only accepts and distributes A first-party-only keystore only accepts and distributes
cryptographically-valid first-party certifications. Given a primary cryptographically-valid first-party certifications. Given a primary
key that the keystore understands, it will only attach user IDs that key that the keystore understands, it will only attach user IDs that
have a valid self-sig, and will only accept and re-distribute subkeys have a valid self-sig, and will only accept and re-distribute subkeys
that are also cryptographically valid (including requiring cross-sigs that are also cryptographically valid (including requiring cross-sigs
for signing-capable subkeys as recommended in [RFC4880]). for signing-capable subkeys as recommended in [RFC4880]).
This effectively avoids certificate flooding attacks, because the This effectively avoids certificate flooding attacks, because the
only party who can make a certificate overly large is the holder of only party who can make a certificate overly large is the holder of
the secret corresponding to the primary key itself. the secret corresponding to the primary key itself.
Note that a first-party-only keystore is still problematic for those Note that a first-party-only keystore is still problematic for those
people who rely on the keystore for retrieval of third-party people who rely on the keystore for retrieval of third-party
certifications. Section 10 attempts to address this lack. certifications. Section 8.3 attempts to address this lack.
9.1. First-party-only Without User IDs 8.2.1. First-party-only Without User IDs
It is possible to operate an first-party-only keystore that It is possible to operate an first-party-only keystore that
redistributes certifications while declining to redistribute user IDs redistributes certifications (in particular, self-sigs) while
(see Section 5.1). This defends against concerns about publishing declining to redistribute user IDs themselves (see Section 5.1).
identifiable information, while enabling full certificate update for This defends against concerns about publishing identifiable
those keystore clients that already know the associated user IDs for information, while enabling full certificate refresh for those
a given certificate. keystore clients that already know the associated user IDs for a
given certificate.
10. First-party-attested Third-party Certifications
We can augment a first-party-only keystore to allow it to distribute
third-party certifications as long as the first-party has signed off
on the specific third-party certification.
An abuse-resistant keystore SHOULD only accept a third-party
certification if it meets the following criteria:
o The third-party certification MUST be cryptographically valid.
Note that this means that the keystore needs to know the primary
key for the issuer of the third-party certification.
o The third-party certification MUST have an unhashed subpacket of
type Embedded Signature, the contents of which we'll call the
"attestation". This attestation is from the certificate's primary
key over the third-party certification itself, as detailed in the
steps below:
* The attestation MUST be an OpenPGP signature packet of type 8.3. First-party-attested Third-party Certifications
0x50 (Third-Party Confirmation signature)
* The attestation MUST contain a hashed "Issuer Fingerprint" We can augment a first-party-only sovereignty-respecting keystore to
subpacket with the fingerprint of the primary key of the allow it to distribute third-party certifications as long as the
certificate in question. first-party has signed off on the specific third-party certification.
* The attestation MUST NOT be marked as non-exportable. A first-party can sign off a third-party certification by creating a
signature over the third-party certification, and attaching it to the
third-party certification as an unhashed subpacket. We call such a
signature an "attestation", and it is created as detailed in the
steps below:
* The attestation MUST contain a hashed Notation subpacket with o The cryptographic validity of the third-party certification SHOULD
the name "ksok", and an empty (0-octet) value. be verified by the first party before creating an attestation for
it. This implies that the issuer key of the third-party
certification must be known by the first party at the time when
the attestation is created.
* The attestation MUST contain a hashed "Signature Target" o The attestation MUST be an OpenPGP signature packet of type 0x50
subpacket with "public-key algorithm" that matches the public- (Third-Party Confirmation signature)
key algorithm of the third-party certification.
* The attestation's hashed "Signature Target" subpacket MUST use o The attestation MUST contain a hashed Signature Creation Time
a reasonably strong hash algorithm (as of this writing, any subpacket whose value is greater than or equal to the hashed
[RFC4880] hash algorithm except MD5, SHA1, or RIPEMD160), and Signature Creation Time subpacket of the third-party
MUST have a hash value equal to the hash over the third-party certification.
certification with all unhashed subpackets removed.
* The attestation MUST be cryptographically valid, verifiable by o The attestation MUST be a signature over the third-party
the primary key of the certificate in question. certification, with all subpackets removed (see the discussion of
signature type 0x50 in section 5.2.4 of [RFC4880]).
This means that a third-party certificate will only be accepted/ o The attestation MUST contain a hashed "Issuer Fingerprint"
distributed by the keystore if: subpacket with the fingerprint of the primary key of the first-
party certificate.
o the keystore knows about both the first- and third-parties. o The attestation MUST contain a hashed Notation subpacket with the
name "first-party-attestation", and an empty (0-octet) value.
o the third-party has made the identity assertion This attestation MUST be embedded in the third-party certification as
an unhashed subpacket of type 32 (Embedded Signature). The simplest
possible OpenPGP certificate with such an attestation looks like the
following sequence of OpenPGP packets (indentation implies
embedding):
o the first-party has confirmed that they're OK with the third-party - A. Primary key
certification being distributed by any keystore. - B. User ID
- C. Self-sig (from A, binding A to B)
- D. Third-party certification (from X, binding A to B)
- E. (embedded unhashed in D: Attestation from A over D)
The "ksok" notification is not strictly necessary for this A sovereignty-respecting keystore MAY check the third-party
mitigation, but it is intended to avoid potential accidental certification itself for cryptographic validity, but explicitly MAY
confusion with any other use of the Third-Party Confirmation also omit this step as long as the first-party attestation is
signature packet type. The author does not know of any current use cryptographically valid. This allows distribution of any certificate
that might collide. as a self-contained unit by verifying only first-party signatures.
It also allows distribution of third-party certifications made by
third-parties unknown to the keystore.
10.1. Key Server Preferences "No-modify" A sovereignty-respecting keystore MUST only accept a third-party
certification if it has a first-party attestation that is
cryptographically valid, verifiable by the primary key of the
certificate in question, and the first-party attestation meets all
the constraints in the list above.
[RFC4880] defines "Key Server Preferences" with a "No-modify" bit. The Notation "first-party-attestation" is intended to avoid potential
That bit has never been respected by any keyserver implementation accidental confusion with any other use of the Third-Party
that the author is aware of. An abuse-resistant keystore following Confirmation signature packet type. The author does not know of any
Section 10 effectively treats that bit as always set, whether it is current use that collides, but there may be future uses that we do
present in the certificate or not. not want to foreclose.
10.2. Client Interactions 8.3.1. Client Interactions
Creating such an attestation requires multiple steps by different Creating such an attestation requires multiple steps by different
parties, each of which is blocked by all prior steps: parties, each of which is blocked by all prior steps:
o The first-party creates the certificate, and transfers it to the o The first-party creates the certificate, and transfers it to the
third party. third party.
o The third-party certifies it, and transfers their certification o The third-party certifies it, and transfers their certification
back to the first party. back to the first party.
skipping to change at page 30, line 30 skipping to change at page 31, line 14
The complexity and length of such a sequence may represent a The complexity and length of such a sequence may represent a
usability obstacle to a user who needs a third-party-certified usability obstacle to a user who needs a third-party-certified
OpenPGP certificate. OpenPGP certificate.
No current OpenPGP client can easily create the attestations No current OpenPGP client can easily create the attestations
described in this section. More implementation work needs to be done described in this section. More implementation work needs to be done
to make it easy (and understandable) for a user to perform this kind to make it easy (and understandable) for a user to perform this kind
of attestation. of attestation.
11. Keystore Client Best Practices 8.3.2. Attestation Revocations
The certificate owner (the "first party") might at some point want to
revoke their attestation over a given third-party certification. For
example: Alice once was friends with Bob, but now thinks that Bob is
a jerk, and wants to avoid public association with him. She used to
be fine with keystores redistributing his certification of her
cryptographic identity, but she no longer wants anyone to do that.
A sovereignty-respecting keystore that distributes third-party
certifications SHOULD respect such a revocation by declining to
distribute the associated third-party certification.
An "attestation revocation" is an OpenPGP signature packet of
signature type 0x30 ("Certification revocation signature"), with the
following properties:
o The attestation revocation MUST contain a hashed Signature
creation Time subpacket whose value is greater than the
attestation it revokes.
o The attestation revocation MUST contain a hashed "Issuer
Fingerprint" subpacket with the fingerprint of the primary key of
the first-party certificate.
o The attestation revocation MUST contain a hashed Notation
subpacket with the name "first-party-attestation" and an empty
(0-octet) value. This Notation MUST be marked as critical. The
criticality is to avoid possible confusion with a revocation of
the third-party certification itself, in the event that the third
party has indicated that the first party is a designated revoker.
o Like any other revocation, the attestation revocation is made over
the same data that the signature it is revoking was made over. In
this case, that means: the third-party certification, with all
subpackets removed (see the discussion of signature type 0x50 in
section 5.2.4 of [RFC4880]).
o The attestation revocation SHOULD contain a hashed "Signature
Target" subpacket with "public-key algorithm" that matches the
public-key algorithm of the attestation. This subpacket makes it
easier for clients and keystores alike to connect an attestation
revocation with an already-known first-party attestation.
o The attestation revocation's hashed "Signature Target" subpacket's
hash algorithm SHOULD be SHA256, and its value MUST be equal to
the hash over the body of the attestation with all unhashed
subpackets removed. That is, the material hashed should be the
octet 0x88, followed by the four-octet length, followed by the
body of the attestation with the unhashed subpacket data length
set to zero.
o The attestation revocation SHOULD be shipped in the sequence of
signature packets after the user ID (in the same location as the
third-party certification itself). This is a different location
than the attestation, for reasons described in Section 8.3.3.
If a keystore or a keystore client expects to see many first-party
attested third-party certifications for a certificate, it SHOULD keep
an index of them (the "attestation index"). To make effective use of
the "Signature Target" subpacket, the attestation index should be
keyed on the SHA256 hash of each indexed attestation, computed the
same way it is computed for the "Signature Target" subpacket. Each
entry in the attestation index should refer to both the attestation
and its attested third-party certification. Note that SHA256 here is
not used for its cryptographic strength, but merely as an efficiency
measure for indexing.
8.3.3. Distribution of Attestation Revocations
The structure of an OpenPGP certificate with a revoked first-party
attestation of a third-party certification looks like this series of
OpenPGP packets (indentation implies embedding):
- A. Primary key
- B. User ID
- C. Self-sig (from A, binding A to B)
- D. Third-party certification (from X, binding A to B)
- E. (embedded unhashed in D: Attestation from A over D)
- F. Attestation Revocation (from A over D, targets+revokes E)
A sovereignty-respecting keystore that sees all of these packets
SHOULD respect Attestation Revocation F by not redistributing D and E
at all.
However, if the keystore is distributing the certificate to a client
that itself may care about first-party attestations (e.g. another
sovereignty-respecting keystore, or just a sovereignty-respecting
client), the keystore SHOULD continue to distribute F, so that the
client can know that E has been revoked.
This means that the redistributed certificate will consist of this
series of OpenPGP packets:
- A. Primary key
- B. User ID
- C. Self-sig (from A, binding A to B)
- F. Attestation Revocation (from A over D, target+revokes E)
A client or keystore that knows about D and E can verify the
signature in F. It can identify E and D by looking them up in the
attestation index based on the "Signature Target" subpacket in F.
or, if it lacks such an index, it can scan all first-party
attestations, and do trial signature verification over all third-
party certifications it knows about until it finds a match.
A client or keystore that doesn't know about D or E MAY ignore and
discard F, since it is not cryptographically verifiable without D and
E. Maintaining an attestation index makes this kind of rejection
much cheaper to compute.
A legacy client or keystore that doesn't understand attestations or
attestation revocations at all might mistake F as an attempt at
revocation of the User ID B itself, due to its signature type, its
placement in the packet stream, and its issuer being A. However,
such a client has three opportunities to ignore this packet and
thereby avoid this confusion efficiently. In increasing order of
computational effort:
o it has a critical notation set that the legacy client (by
definition) does not understand, and should therefore reject.
o it has a Signature Target that does not match Self-sig C.
o it does not cryptographically validate when computed over A and B.
8.3.4. Revoking Third-party Certifications
A sovereignty-respecting keystore distributes a third-party
certification based on the desires of the first party, but the third-
party themselves may change their mind about the certification that
they issued. In particular, they may revoke a previously attested
third-party certification. This causes some additional complexity.
8.3.4.1. Third-party Certification Revocations Aren't Shipped with the
Certificate
Distributing the third-party's revocation of their certification
without the approval of the first party would arguably disrespect the
first-party's sovereignty over their own certificate. For example,
consider an abusively large revocation, or a revocation which
contains toxic data.
At the same time, if the first party were to revoke their
attestation, then the third-party certification itself _and_ its
third-party's revocation might not be distributed. So distributing
third-party certification revocations directly on the certificate
they refer to doesn't seem to solve the problem for an abuse-
resistant, sovereignty-respecting keystore.
8.3.4.2. Third-party Certification Revocations Ship With the Issuing
Certificate
Instead, a sovereignty-respecting keystore MAY ship a third-party
certification revocation attached to the end of the issuing
certificate, as this respects the sovereignty of all parties
involved.
Using the same packet references as Section 8.3, this means that the
certifier's own OpenPGP certificate MAY be distributed like so:
- X. Primary key
- G. User ID
- H. Self-sig (from X, binding X to G)
- I. Subkey
- J. Subkey binding signature (from X, binds I to X)
- K. Certification revocation signature
(from X over A and B, targets+revokes D)
Note that OpenPGP packet K is unusual here, and augments the
traditional Transferable Public Key structure from [RFC4880].
A client that cares about third-party certifications SHOULD maintain
an index of certifications based on the SHA256 digest of the
certifications themselves (the "certification index"). The
certification revocation packet SHOULD contain a Signature Target
subpacket using SHA256 to identify the revoked certification. The
client can use this Signature Target subpacket and the certification
index to identify the targeted certification and to compute the data
over which the revocation is made. As with the attestation index
described in Section 8.3.2, this use of SHA256 is not used for
cryptographic strength, but for indexing efficiency.
A client that cares about third-party certifications from key X
SHOULD refresh the certificate containing X from the keystore, and
verify any discovered certification revocations correctly to the
appropriate certificates, searching for the targeted revocation in
its certification index.
A legacy client that is unaware of this augmentation of the
Transferable Public Key structure is likely to consider packet K as
out-of-order or inapplicable (it would typically expect only a Subkey
Revocation Signature packet in this position), and so will discard
it.
In the event that the certificate has no subkeys (packets I and J are
absent), a legacy client might consider K to be an attempt to revoke
Self-Sig H. However, K's Signature Target subpacket does not point
to H, and the certification is not cryptographically valid over X and
G, so it should be discarded/ignored safely in that case as well.
9. Keystore Client Best Practices
An OpenPGP client that needs to interact with an abuse-resistant An OpenPGP client that needs to interact with an abuse-resistant
keystore can take steps to minimize the extent that its interactions keystore can take steps to minimize the extent that its interactions
with a keystore can be abused by other parties via the attacks with a keystore can be abused by other parties via the attacks
described in Section 2. This section describes steps that an abuse- described in Section 2. This section describes steps that an abuse-
resistant client can take. resistant client can take.
11.1. Use Constrained Keystores for Lookup 9.1. Use Constrained Keystores for Lookup
When performing certificate lookup, an abuse-resistant client SHOULD When performing certificate lookup, an abuse-resistant client SHOULD
prefer to query constrained keystores to avoid the risks described in prefer to query abuse-resistant keystores to avoid the risks
Section 15.1. described in Section 13.1. In particular, keystores that defend
against User ID Flooding are significantly more reliable for
certificate lookup.
11.2. Normalize Addresses and User IDs for Lookup 9.2. Normalize Addresses and User IDs for Lookup
When performing lookup by e-mail address, an abuse-resistant client When performing lookup by e-mail address, an abuse-resistant client
SHOULD consider canonicalizing the e-mail address before searching SHOULD consider canonicalizing the e-mail address before searching
(see Section 14.3). (see Section 12.3).
When searching by full User ID, unless there is a strong reason to When searching by full User ID, unless there is a strong reason to
believe that a specific non-normalized form is preferable, an abuse- believe that a specific non-normalized form is preferable, an abuse-
resistant client SHOULD normalize the entire user ID into resistant client SHOULD normalize the entire user ID into
[UNICODE-NORMALIZATION] Form C (NFC) before performing certificate [UNICODE-NORMALIZATION] Form C (NFC) before performing certificate
lookup. lookup.
11.3. Avoid Fuzzy Lookups 9.3. Avoid Fuzzy Lookups
Certificate lookup by arbitrary substring matching, or regular Certificate lookup by arbitrary substring matching, or regular
expression is prone to abuse. An abuse-resistant client SHOULD expression is prone to abuse. An abuse-resistant client SHOULD
prefer exact-userid or exact-email match lookups where possible. prefer exact-uid or exact-email match lookups where possible.
In particular, an abuse-resistant client should avoid trying to offer In particular, an abuse-resistant client should avoid trying to offer
reliable functionality that performs these sort of fuzzy lookups, and reliable functionality that performs these sort of fuzzy lookups, and
SHOULD warn the user about risks of abuse if the user triggers a SHOULD warn the user about risks of abuse if the user triggers a
codepath that unavoidably performs such a fuzzy lookup. codepath that unavoidably performs such a fuzzy lookup.
11.4. Prefer Full Fingerprint for Discovery and Update 9.4. Prefer Full Fingerprint for Discovery and Refresh
Key IDs are inherently weaker and easier to spoof or collide than Key IDs are inherently weaker and easier to spoof or collide than
full fingerprints. Where possible, an abuse-resistant keystore full fingerprints. Where possible, an abuse-resistant keystore
client SHOULD use the full fingerprint when interacting with the client SHOULD use the full fingerprint when interacting with the
keystore. keystore.
11.5. Use Caution with Keystore-provided Validation 9.5. Use Caution with Keystore-provided Validation
When an abuse-resistant client relies on a keystore for certificate When an abuse-resistant client relies on a keystore for certificate
validation, many things can go subtly wrong if the client fails to validation, many things can go subtly wrong if the client fails to
closely track the specific semantics of the keystore's validation closely track the specific semantics of the keystore's validation
claims. claims.
For example, a certificate published by WKD For example, a certificate published by WKD
([I-D.koch-openpgp-webkey-service]) at ([I-D.koch-openpgp-webkey-service]) at
"https://openpgpkey.example.org/.well-known/openpgpkey/hu/ "https://openpgpkey.example.org/.well-known/openpgpkey/hu/
iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=joe.doe" offers a validation claim iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=joe.doe" offers a validation claim
skipping to change at page 32, line 7 skipping to change at page 36, line 50
When certificate validation is represented more generally by a When certificate validation is represented more generally by a
keystore via certificate retrieval (e.g. from an e-mail validating keystore via certificate retrieval (e.g. from an e-mail validating
keyserver that has no distinct certificate validation interface), the keyserver that has no distinct certificate validation interface), the
thing validated is the certificate received from the keystore, and thing validated is the certificate received from the keystore, and
not the result of the merge into any local copy of the certificate not the result of the merge into any local copy of the certificate
already possessed by the client. already possessed by the client.
Consider also timing and duration of these assertions of validity, Consider also timing and duration of these assertions of validity,
which represent a subtle tradeoff between privacy and risk as which represent a subtle tradeoff between privacy and risk as
described in Section 16.4. described in Section 14.4.
12. Certificate Generation and Management Best Practices 10. Certificate Generation and Management Best Practices
An OpenPGP implementation that generates or manages certificates and An OpenPGP implementation that generates or manages certificates and
expects to distribute them via abuse-resistant keystores can take expects to distribute them via abuse-resistant keystores can take
steps to ensure that the certificates generated are more likely to be steps to ensure that the certificates generated are more likely to be
accessible when needed. This section describes steps such an abuse- accessible when needed. This section describes steps such an abuse-
sensitive implementation can take. sensitive implementation can take.
12.1. Canonicalized E-Mail Addresses 10.1. Canonicalized E-Mail Addresses
E-mail addresses can be written in many different ways. An abuse- E-mail addresses can be written in many different ways. An abuse-
sensitive implementation considering attaching a user ID containing sensitive implementation considering attaching a user ID containing
an e-mail address on a certificate SHOULD ensure that the e-mail an e-mail address on a certificate SHOULD ensure that the e-mail
address is structured as simply as possible. See Section 14.3 for address is structured as simply as possible. See Section 12.3 for
details about e-mail address canonicalization. details about e-mail address canonicalization.
For example, if the e-mail domain considers the local part to be For example, if the e-mail domain considers the local part to be
case-insensitive (as most e-mail domains do today), if a proposed case-insensitive (as most e-mail domains do today), if a proposed
user ID contains the "addr-spec": "Alice@EXAMPLE.org", the user ID contains the "addr-spec": "Alice@EXAMPLE.org", the
implementation SHOULD warn the user and, if possible, propose implementation SHOULD warn the user and, if possible, propose
replacing the "addr-spec" part of the user ID with replacing the "addr-spec" part of the user ID with
"alice@example.org". "alice@example.org".
12.2. Normalized User IDs 10.2. Normalized User IDs
User IDs are arbitrary UTF-8 strings, but UTF-8 offers several ways User IDs are arbitrary UTF-8 strings, but UTF-8 offers several ways
to represent the same string. An abuse-sensitive implementation to represent the same string. An abuse-sensitive implementation
considering attaching a user ID to a certificate SHOULD normalize the considering attaching a user ID to a certificate SHOULD normalize the
string using [UNICODE-NORMALIZATION] Form C (NFC) before creating the string using [UNICODE-NORMALIZATION] Form C (NFC) before creating the
self-sig. self-sig.
At the same time, the implementation MAY also warn the user if the At the same time, the implementation MAY also warn the user if the
"compatibility" normalized form (NFKC) differs from the candidate "compatibility" normalized form (NFKC) differs from the candidate
user ID and, if appropriate, offer to convert the user ID to user ID and, if appropriate, offer to convert the user ID to
compatibility normalized form at the user's discretion. compatibility normalized form at the user's discretion.
12.3. Avoid Large User Attributes 10.3. Avoid Large User Attributes
An abuse-sensitive implementation SHOULD warn the user when attaching An abuse-sensitive implementation SHOULD warn the user when attaching
a user attribute larger than 8383 octets, and SHOULD refuse to attach a user attribute larger than 8383 octets, and SHOULD refuse to attach
user attributes entirely larger than 65536 octets. (See Section 4.1) user attributes entirely larger than 65536 octets. (See Section 4.1)
12.4. Provide Cross-Sigs 10.4. Provide Cross-Sigs
[RFC4880] requires cross-sigs for all signing-capable subkeys, but is [RFC4880] requires cross-sigs for all signing-capable subkeys, but is
agnostic about the use of cross-sigs for subkeys of other agnostic about the use of cross-sigs for subkeys of other
capabilities. capabilities.
An abuse-sensitive implementation that wants a certificate to be An abuse-sensitive implementation that wants a certificate to be
discoverable by subkey SHOULD provide cross-sigs for any subkey discoverable by subkey SHOULD provide cross-sigs for any subkey
capable of making a cross-sig. capable of making a cross-sig.
12.5. Provide Issuer Fingerprint Subpackets 10.5. Provide Issuer Fingerprint Subpackets
Issuer subpackets contain only 64-bit key IDs. Issuer Fingerprint Issuer subpackets contain only 64-bit key IDs. Issuer Fingerprint
subpackets contain an unambiguous designator of the issuing key, subpackets contain an unambiguous designator of the issuing key,
avoiding the ambiguities described in Section 13.2. Abuse-sensitive avoiding the ambiguities described in Section 11.2. Abuse-sensitive
implementations SHOULD providue Issuer Fingerprint subpackets. implementations SHOULD provide Issuer Fingerprint subpackets.
12.6. Put Cross-Sigs and Issuer Fingerprint in Hashed Subpackets 10.6. Put Cross-Sigs and Issuer Fingerprint in Hashed Subpackets
Unhashed subpackets may be stripped or mangled. Placing cross-sigs Unhashed subpackets may be stripped or mangled. Placing cross-sigs
and issuer fingerprint subpackets in the hashed subpackets will and issuer fingerprint subpackets in the hashed subpackets will
ensure that they are propagated by any cryptographically-validating ensure that they are propagated by any cryptographically-validating
keystore, even if that keystore fails to observe the exceptions in keystore, even if that keystore fails to observe the exceptions in
Section 4.4. Section 4.4.
12.7. Submit Certificates to Restricted, Lookup-Capable Keystores 10.7. Submit Certificates to Restricted, Lookup-Capable Keystores
If an abuse-sensitive implementation wants other peers to be able to If an abuse-sensitive implementation wants other peers to be able to
to retrieve the managed certificate by certificate lookup (that is, to retrieve the managed certificate by certificate lookup (that is,
by searching based on user ID or e-mail address), it needs to be by searching based on user ID or e-mail address), it needs to be
aware that submission to an unrestricted keystore is not reliable aware that submission to an unrestricted keystore is not reliable
(see Section 15.1 for more details). (see Section 13.1 for more details).
Consequently, such an implementation SHOULD submit the managed Consequently, such an implementation SHOULD submit the managed
certificate to restricted, lookup-capable keystores where possible, certificate to restricted, lookup-capable keystores where possible,
as those keystores are more likely to be able to offer reliable as those keystores are more likely to be able to offer reliable
lookup. lookup.
13. Side Effects and Ecosystem Impacts 11. Side Effects and Ecosystem Impacts
13.1. Designated Revoker 11.1. Designated Revoker
A first-party-only keystore as described in Section 9 might decline A first-party-only keystore as described in Section 8.2 might decline
to distribute revocations made by the designated revoker. This is a to distribute revocations made by the designated revoker. This is a
risk to certificate-holder who depend on this mechanism, because an risk to certificate-holder who depend on this mechanism, because an
important revocation might be missed by clients depending on the important revocation might be missed by clients depending on the
keystore. keystore.
FIXME: adjust this document to point out where revocations from a FIXME: adjust this document to point out where revocations from a
designated revoker SHOULD be propagated, maybe even in first-party- designated revoker SHOULD be propagated, maybe even in first-party-
only keystores. only keystores.
13.2. Key IDs vs. Fingerprints in Certificate Discovery 11.2. Key IDs vs. Fingerprints in Certificate Discovery
During signature verification, a user performing certificate During signature verification, a user performing certificate
discovery against a keystore SHOULD prefer to use the full discovery against a keystore SHOULD prefer to use the full
fingerprint as an index, rather than the 64-bit key ID. Using a fingerprint as an index, rather than the 64-bit key ID. Using a
64-bit key ID is more likely to run into collision attacks; and if 64-bit key ID is more likely to run into collision attacks; and if
the retrieved certificate has a matching key ID but the signature the retrieved certificate has a matching key ID but the signature
cannot be validated with it, the client is in an ambiguous state - cannot be validated with it, the client is in an ambiguous state -
did it retrieve the wrong certificate, or is the signature incorrect? did it retrieve the wrong certificate, or is the signature incorrect?
Using the fingerprint resolves the ambiguity: the signature is Using the fingerprint resolves the ambiguity: the signature is
incorrect, because the a fingerprint match is overwhelmingly stronger incorrect, because the a fingerprint match is overwhelmingly stronger
skipping to change at page 34, line 33 skipping to change at page 39, line 29
with only an Issuer subpacket, so a client attempting to find such a with only an Issuer subpacket, so a client attempting to find such a
certificate MAY perform certificate discovery based on only the key certificate MAY perform certificate discovery based on only the key
ID. ID.
A keystore that offers certificate discovery MAY choose to require A keystore that offers certificate discovery MAY choose to require
full fingerprint, but such a keystore will not be useful for a client full fingerprint, but such a keystore will not be useful for a client
attempting to verify a bare signature from an unknown party if that attempting to verify a bare signature from an unknown party if that
signature only has an Issuer subpacket (and no Issuer Fingerprint signature only has an Issuer subpacket (and no Issuer Fingerprint
subpacket). subpacket).
13.3. In-band Certificates 11.3. In-band Certificates
There are contexts where it is expected and acceptable that the There are contexts where it is expected and acceptable that the
signature appears without its certificate: for example, if the set of signature appears without its certificate: for example, if the set of
valid signers is already known (as in some OpenPGP-signed operating valid signers is already known (as in some OpenPGP-signed operating
system updates), shipping the certificate alongside the signature system updates), shipping the certificate alongside the signature
would be pointless bloat. would be pointless bloat.
However, OpenPGP signatures are often found in contexts where the However, OpenPGP signatures are often found in contexts where the
certificate is not yet known by the verifier. For example, many certificate is not yet known by the verifier. For example, many
OpenPGP-signed e-mails are not accompanied by the signing OpenPGP-signed e-mails are not accompanied by the signing
skipping to change at page 35, line 9 skipping to change at page 40, line 4
In another example, the use of authentication-capable OpenPGP keys in In another example, the use of authentication-capable OpenPGP keys in
standard SSH connections do not contain the full OpenPGP standard SSH connections do not contain the full OpenPGP
certificates, which means that the SSH clients and servers need to certificates, which means that the SSH clients and servers need to
resort to out-of-band processes if evaluation of the OpenPGP resort to out-of-band processes if evaluation of the OpenPGP
certificates is necessary. certificates is necessary.
The certificate discovery interface offered by keystores is an The certificate discovery interface offered by keystores is an
attempt to accommodate these situations. But in the event that a attempt to accommodate these situations. But in the event that a
keystore is unavailable, does not know the certificate, or suffers keystore is unavailable, does not know the certificate, or suffers
from a flooding attack, signature validation may fail unnecessarily. from a flooding attack, signature validation may fail unnecessarily.
In an encrypted e-mail context specifically, such a failure may also In an encrypted e-mail context specifically, such a failure may also
limit the client's ability to reply with an encrypted e-mail. limit the client's ability to reply with an encrypted e-mail.
Certificate discovery also presents a potential privacy concern for Certificate discovery also presents a potential privacy concern for
the signature verifier, as noted in Section 16.5. the signature verifier, as noted in Section 14.5.
These problematic situations can be mitigated by shipping the These problematic situations can be mitigated by shipping the
certificate in-band, alongside the signature. Signers SHOULD adopt certificate in-band, alongside the signature. Signers SHOULD adopt
this practice where possible to reduce the dependence of the verifier this practice where possible to reduce the dependence of the verifier
on the keystores for certificate discovery. [AUTOCRYPT] is an on the keystores for certificate discovery. [AUTOCRYPT] is an
example of e-mail recommendations that include in-band certificates. example of e-mail recommendations that include in-band certificates.
13.3.1. In-band Certificate Minimization and Validity 11.3.1. In-band Certificate Minimization and Validity
OpenPGP certificates are potenitally large. When distributing an in- OpenPGP certificates are potentially large. When distributing an in-
band certificate alongside a signature in a context where size is a band certificate alongside a signature in a context where size is a
concern (e.g. bandwidth, latency, or storage costs are a factor), the concern (e.g. bandwidth, latency, or storage costs are a factor), the
distributor SHOULD reduce the size of the in-band certificate by distributor SHOULD reduce the size of the in-band certificate by
stripping unnecessary packets. For example, the distributor may: stripping unnecessary packets. For example, the distributor may:
o Strip certification and signature packets that (due to creation o Strip certification and signature packets that (due to creation
and expiration time) are not relevant to the time of the signature and expiration time) are not relevant to the time of the signature
itself. This ensures that the reduced certificate is itself. This ensures that the reduced certificate is
contemporaneously valid with the signature. contemporaneously valid with the signature.
skipping to change at page 36, line 5 skipping to change at page 40, line 50
o Strip user IDs (and associated certifications) that are unlikely o Strip user IDs (and associated certifications) that are unlikely
to be relevant to the signature in question. For example, in the to be relevant to the signature in question. For example, in the
e-mail context, strip any user IDs that do not match the declared e-mail context, strip any user IDs that do not match the declared
sender of the message. sender of the message.
o Strip third-party certifications that are unlikely to be relevant o Strip third-party certifications that are unlikely to be relevant
to the verifier. Doing this successfully requires some knowledge to the verifier. Doing this successfully requires some knowledge
about what the third-parties the recipient is likely to care about what the third-parties the recipient is likely to care
about. Stripping all third-party certifications is a simple means about. Stripping all third-party certifications is a simple means
of certificate reduction. The verifier of such a certificate may of certificate reduction. The verifier of such a certificate may
need to do certificate update against their preferred keystore to need to do certificate refresh against their preferred keystore to
learn about third-party certifications useful to them. learn about third-party certifications useful to them.
13.4. Certification-capable Subkeys 11.4. Certification-capable Subkeys
Much of this discussion assumes that primary keys are the only Much of this discussion assumes that primary keys are the only
certification-capable keys in the OpenPGP ecosystem. Some proposals certification-capable keys in the OpenPGP ecosystem. Some proposals
have been put forward that assume that subkeys can be marked as have been put forward that assume that subkeys can be marked as
certification-capable. If subkeys are certification-capable, then certification-capable. If subkeys are certification-capable, then
much of the reasoning in this draft becomes much more complex, as much of the reasoning in this draft becomes much more complex, as
subkeys themselves can be revoked by their primary key without subkeys themselves can be revoked by their primary key without
invalidating the key material itself. That is, a subkey can be both invalidating the key material itself. That is, a subkey can be both
valid (in one context) and invalid (in another context) at the same valid (in one context) and invalid (in another context) at the same
time. So questions about what data can be dropped (e.g. in time. So questions about what data can be dropped (e.g. in
Section 7) are much fuzzier, and the underlying assumptions may need Section 7) are much fuzzier, and the underlying assumptions may need
to be reviewed. to be reviewed.
If some OpenPGP implementations accept certification-capable subkeys, If some OpenPGP implementations accept certification-capable subkeys,
but an abuse-resistant keystore does not accept certifications from but an abuse-resistant keystore does not accept certifications from
subkeys in general, then interactions between that keystore and those subkeys in general, then interactions between that keystore and those
implementations may be surprising. implementations may be surprising.
13.5. Assessing Certificates in the Past 11.5. Assessing Certificates in the Past
Online protocols like TLS perform signature and certificate Online protocols like TLS perform signature and certificate
evaluation based entirely on the present time. If a certificate that evaluation based entirely on the present time. If a certificate that
signs a TLS handshake message is invalid now, it doesn't matter signs a TLS handshake message is invalid now, it doesn't matter
whether it was valid a week ago, because the present TLS session is whether it was valid a week ago, because the present TLS session is
the context of the evaluation. the context of the evaluation.
But OpenPGP signatures are often evaluated at some temporal remove But OpenPGP signatures are often evaluated at some temporal remove
from when the signature was made. For example, software packages are from when the signature was made. For example, software packages are
signed at release time, but those signatures are validated at signed at release time, but those signatures are validated at
skipping to change at page 37, line 5 skipping to change at page 41, line 47
against some set of keystores to find a certificate with which to against some set of keystores to find a certificate with which to
check the signature. check the signature.
Further complicating matters, the composable nature of an OpenPGP Further complicating matters, the composable nature of an OpenPGP
certificate means that the certificate associated with any particular certificate means that the certificate associated with any particular
signing key (primary key or subkey) can transform over time. So when signing key (primary key or subkey) can transform over time. So when
evaluating a signature that appears to have been made by a given evaluating a signature that appears to have been made by a given
certificate, it may be better to try to evaluate the certificate at certificate, it may be better to try to evaluate the certificate at
the time the signature was made, rather than the present time. the time the signature was made, rather than the present time.
13.5.1. Point-in-time Certificate Evaluation 11.5.1. Point-in-time Certificate Evaluation
When evaluating a certificate at a time T in the past (for example, When evaluating a certificate at a time T in the past (for example,
when trying to validate a data signature by that certificate that was when trying to validate a data signature by that certificate that was
created at time T), one approach is to discard all packets from the created at time T), one approach is to discard all packets from the
certificate if the packet has a creation time later than T. Then certificate if the packet has a creation time later than T. Then
evaluate the resulting certificate from the remaining packets in the evaluate the resulting certificate from the remaining packets in the
context of time T. context of time T.
However, any such evaluation MUST NOT ignore "hard" OpenPGP key However, any such evaluation MUST NOT ignore "hard" OpenPGP key
revocations, regardless of their creation date. (see Section 14.1). revocations, regardless of their creation date. (see Section 12.1).
13.5.2. Signature Verification and Non-append-only Keystores 11.5.2. Signature Verification and Non-append-only Keystores
If a non-append-only keystore (Section 7) has dropped superseded If a non-append-only keystore (Section 7) has dropped superseded
(Section 7.1) or expired (Section 7.2) certifications, it's possible (Section 7.1) or expired (Section 7.2) certifications, it's possible
for the certificate composed of the remaining packets to have no for the certificate composed of the remaining packets to have no
valid first-party certification at the time that a given signature valid first-party certification at the time that a given signature
was made. If a user performs certificate discovery against such a was made. If a user performs certificate discovery against such a
keystore, the certificate it retrieves would be invalid according to keystore, the certificate it retrieves would be invalid according to
[RFC4880], and consequently verification of any signature by that [RFC4880], and consequently verification of any signature by that
certificate would fail. certificate would fail.
One simple mitigation to this problem is to ship a contemporaneously- One simple mitigation to this problem is to ship a contemporaneously-
valid certificate in-band alongside the signature (see Section 13.3). valid certificate in-band alongside the signature (see Section 11.3).
If the distributor does this, then the verifier need only learn about If the distributor does this, then the verifier need only learn about
revocations. If knowledge about revocation is needed, the verifier revocations. If knowledge about revocation is needed, the verifier
might perform a certificate update (not "certificate discovery") might perform a certificate refresh (not "certificate discovery")
against any preferred keystore, including non-append-only keystores, against any preferred keystore, including non-append-only keystores,
merging what it learns into the in-band contemporary certificate. merging what it learns into the in-band contemporary certificate.
Then the signature verifier can follow the certificate evaluation Then the signature verifier can follow the certificate evaluation
process outlined in Section 13.5.1, using the merged certificate. process outlined in Section 11.5.1, using the merged certificate.
13.6. Global Append-only Ledgers ("Blockchain") 11.6. Global Append-only Ledgers ("Blockchain")
The append-only aspect of some OpenPGP keystores encourages a user of The append-only aspect of some OpenPGP keystores encourages a user of
the keystore to rely on that keystore as a faithful reporter of the keystore to rely on that keystore as a faithful reporter of
history, and one that will not misrepresent or hide the history that history, and one that will not misrepresent or hide the history that
they know about. An unfaithful "append-only" keystore could abuse they know about. An unfaithful "append-only" keystore could abuse
the trust in a number of ways, including withholding revocation the trust in a number of ways, including withholding revocation
certificates, offering different sets of certificates to different certificates, offering different sets of certificates to different
clients doing certificate lookup, and so on. clients doing certificate lookup, and so on.
However, the most widely used append-only OpenPGP keystore, the [SKS] However, the most widely used append-only OpenPGP keystore, the [SKS]
skipping to change at page 39, line 5 skipping to change at page 43, line 47
by identity providers, however. And both offer the ability to detect by identity providers, however. And both offer the ability to detect
a misbehaving identity provider, but no specific enforcement or a misbehaving identity provider, but no specific enforcement or
recovery strategies against such an actor. recovery strategies against such an actor.
It's conceivable that a keystore could piggyback on the CT logs or It's conceivable that a keystore could piggyback on the CT logs or
other blockchain/ledger mechanisms like [BITCOIN] to store other blockchain/ledger mechanisms like [BITCOIN] to store
irrevocable pieces of data (such as revocation certificates). irrevocable pieces of data (such as revocation certificates).
Further work is needed to describe how to do this in an effective and Further work is needed to describe how to do this in an effective and
performant way. performant way.
13.7. Certificate Lookup for Identity Monitoring 11.7. Certificate Lookup for Identity Monitoring
A typical use case for certificate lookup is a user looking for a While certificate lookup is classically used to find a key to encrypt
certificate in order to be able to encrypt an outbound message an outbound message to, another use case for certificate lookup is
intended for a given e-mail address, but this is not the only use for the party in control of a particular identity to determine
case. whether anyone else is claiming that identity.
Another use caes is when the party in control of a particular That is, a client in control of the secret key material associated
identity wants to determine whether anyone else is claiming that with a particular certificate with user ID X might search a keystore
identity. That is, a client in control of the secret key material for all certificates matching X in order to find out whether any
associated with a particular certificate with user ID X might search other certificates claim it.
a keystore for all certificates matching X in order to find out
whether any other certificates claim it.
This is an important safeguard as part of the ledger-based detection This is an important safeguard as part of the ledger-based detection
mechanisms described in Section 13.6, but may also be useful for mechanisms described in Section 11.6, but may also be useful for
keystores in general. keystores in general.
However, identity monitoring against a keystore that does not defend However, identity monitoring against a keystore that does not defend
against user ID flooding (Section 2.2) is expensive and potentially against user ID flooding (Section 2.2) is expensive and potentially
of limited value. In particular, a malicious actor with a of limited value. In particular, a malicious actor with a
certificate which duplicates a given User ID could flood the keystore certificate which duplicates a given User ID could flood the keystore
with similar certificates, hiding whichever one is in malicious use. with similar certificates, hiding whichever one is in malicious use.
Since such a keystore is not considered authoritative by any Since such a keystore is not considered authoritative by any
reasonable client for the user ID in question, this attack forces the reasonable client for the user ID in question, this attack forces the
identity-monitoring defender to spend arbitrary resources fetching identity-monitoring defender to spend arbitrary resources fetching
and evaluating each certificate in the flood, without knowing which and evaluating each certificate in the flood, without knowing which
certificate other clients might be evaluating. certificate other clients might be evaluating.
14. OpenPGP details 12. OpenPGP details
This section collects details about common OpenPGP implementation This section collects details about common OpenPGP implementation
behavior that are useful in evaluating and reasoning about OpenPGP behavior that are useful in evaluating and reasoning about OpenPGP
certificates. certificates.
14.1. Revocations 12.1. Revocations
It's useful to classify OpenPGP revocations of key material into two It's useful to classify OpenPGP revocations of key material into two
categories: "soft" and "hard". categories: "soft" and "hard".
If the "Reason for Revocation" of an OpenPGP key is either "Key is If the "Reason for Revocation" of an OpenPGP key is either "Key is
superseded" or "Key is retired and no longer used", it is a "soft" superseded" or "Key is retired and no longer used", it is a "soft"
revocation. revocation.
An implementation that interprets a "soft" revocation will typically An implementation that interprets a "soft" revocation will typically
not invalidate signatures made by the associated key with a creation not invalidate signatures made by the associated key with a creation
skipping to change at page 40, line 26 skipping to change at page 45, line 20
these two categories. these two categories.
A defensive OpenPGP implementation that does not distinguish between A defensive OpenPGP implementation that does not distinguish between
these two categories SHOULD treat all revocations as "hard". these two categories SHOULD treat all revocations as "hard".
An implementation aware of a "soft" revocation or of key or An implementation aware of a "soft" revocation or of key or
certificate expiry at time T SHOULD accept and process a "hard" certificate expiry at time T SHOULD accept and process a "hard"
revocation even if it appears to have been issued at a time later revocation even if it appears to have been issued at a time later
than T. than T.
14.2. User ID Conventions 12.2. User ID Conventions
[RFC4880] requires a user ID to be a UTF-8 string, but does not [RFC4880] requires a user ID to be a UTF-8 string, but does not
constrain it beyond that. In practice, a handful of conventions constrain it beyond that. In practice, a handful of conventions
predominate in how User IDs are formed. predominate in how User IDs are formed.
The most widespread convention is a "name-addr" as defined in The most widespread convention is a "name-addr" as defined in
[RFC5322]. For example: [RFC5322]. For example:
Alice Jones <alice@example.org> Alice Jones <alice@example.org>
skipping to change at page 41, line 9 skipping to change at page 46, line 5
Alice Jones Alice Jones
Still other certificates identify a particular network service by Still other certificates identify a particular network service by
scheme and hostname. For example, the administrator of an ssh host scheme and hostname. For example, the administrator of an ssh host
participating in the [MONKEYSPHERE] might choose a user ID for the participating in the [MONKEYSPHERE] might choose a user ID for the
OpenPGP representing the host like so: OpenPGP representing the host like so:
ssh://foo.example.net ssh://foo.example.net
14.3. E-mail Address Canonicalization 12.3. E-mail Address Canonicalization
When an OpenPGP user IDs includes an "addr-spec", there still may be When an OpenPGP user IDs includes an "addr-spec", there still may be
multiple ways of representing the addr-spec that refer to the same multiple ways of representing the addr-spec that refer to the same
underlying mailbox. Having a truly canonical form of an "addr-spec" underlying mailbox. Having a truly canonical form of an "addr-spec"
is probably impossible because of legacy deployments of mailservers is probably impossible because of legacy deployments of mailservers
that do odd things with the local part, but e-mail addresses used in that do odd things with the local part, but e-mail addresses used in
an abuse-resistant ecosystem SHOULD be constrained enough to admit to an abuse-resistant ecosystem SHOULD be constrained enough to admit to
some sensible form of canonicalization. some sensible form of canonicalization.
14.3.1. Disallowing Non-UTF-8 Local Parts 12.3.1. Disallowing Non-UTF-8 Local Parts
In [RFC5322], the "local-part" can be any "dot-atom". But if this is In [RFC5322], the "local-part" can be any "dot-atom". But if this is
[RFC2047] decoded, it could be any arbitrary charset, not necessarily [RFC2047] decoded, it could be any arbitrary charset, not necessarily
UTF-8. FIXME: Do we convert from the arbitrary charset to UTF-8? UTF-8. FIXME: Do we convert from the arbitrary charset to UTF-8?
14.3.2. Domain Canonicalization 12.3.2. Domain Canonicalization
FIXME: should domain name be canonicalized into punycode form? User FIXME: should domain name be canonicalized into punycode form? User
IDs are typically user-facing, so i think the canonicalized form IDs are typically user-facing, so i think the canonicalized form
should be the [UNICODE-NORMALIZATION] Form C (NFC) of the domain should be the [UNICODE-NORMALIZATION] Form C (NFC) of the domain
name. Can we punt to some other draft here? name. Can we punt to some other draft here?
14.3.3. Local Part Canonicalization 12.3.3. Local Part Canonicalization
FIXME: [I-D.koch-openpgp-webkey-service] recommends downcasing all FIXME: [I-D.koch-openpgp-webkey-service] recommends downcasing all
ASCII characters in the left-hand side, but leaves all ASCII characters in the left-hand side, but leaves all
15. Security Considerations 13. Security Considerations
This document offers guidance on mitigating a range of denial-of- This document offers guidance on mitigating a range of denial-of-
service attacks on public keystores, so the entire document is in service attacks on public keystores, so the entire document is in
effect about security considerations. effect about security considerations.
Many of the mitigations described here defend individual OpenPGP Many of the mitigations described here defend individual OpenPGP
certificates against flooding attacks (see Section 2.1). But only certificates against flooding attacks (see Section 2.1). But only
some of these mitigations defend against flooding attacks against the some of these mitigations defend against flooding attacks against the
keystore itself (see Section 2.4), or against flooding attacks on the keystore itself (see Section 2.4), or against flooding attacks on the
space of possible user IDs (see Section 2.2). Thoughtful threat space of possible user IDs (see Section 2.2). Thoughtful threat
modeling and monitoring of the keystore and its defenses are probably modeling and monitoring of the keystore and its defenses are probably
necessary to maintain the long-term health of the keystore. necessary to maintain the long-term health of the keystore.
Section 13.1 describes a potentially scary security problem for Section 11.1 describes a potentially scary security problem for
designated revokers. designated revokers.
TODO (more security considerations) TODO (more security considerations)
15.1. Tension Between Unrestricted Uploads and Certificate Lookup 13.1. Tension Between Unrestricted Uploads and Certificate Lookup
Note that there is an inherent tension between accepting arbitrary Note that there is an inherent tension between accepting arbitrary
certificate uploads and permitting effective certificate lookup. If certificate uploads and permitting effective certificate lookup. If
a keystore accepts arbitrary certificate uploads for redistribution, a keystore accepts arbitrary certificate uploads for redistribution,
it appears to be vulnerable to user ID flooding (Section 2.2), which it appears to be vulnerable to user ID flooding (Section 2.2), which
makes it difficult or impossible to rely on for certificate lookup. makes it difficult or impossible to rely on for certificate lookup.
In the broader ecosystem, it may be necessary to use gated/controlled In the broader ecosystem, it may be necessary to use gated/controlled
certificate lookup mechanisms. For example, both certificate lookup mechanisms. For example, both
[I-D.koch-openpgp-webkey-service] and [RFC7929] enable the [I-D.koch-openpgp-webkey-service] and [RFC7929] enable the
administrator of a DNS domain to distribute certificates associated administrator of a DNS domain to distribute certificates associated
with e-mail addresses within that domain, while excluding other with e-mail addresses within that domain, while excluding other
parties. As a rather different example, [I-D.mccain-keylist] offers parties. As a rather different example, [I-D.mccain-keylist] offers
certificate lookup on the basis of interest - a client interested in certificate lookup on the basis of interest - a client interested in
an organization can use that mechanism to learn what certificates an organization can use that mechanism to learn what certificates
that organization thinks are worth knowing about, associated with a that organization thinks are worth knowing about, associated with a
range of identities regardless of the particular DNS domain. Note range of identities regardless of the particular DNS domain. Note
that [I-D.mccain-keylist] does not provide the certificates directly, that [I-D.mccain-keylist] does not provide the certificates directly,
but instead expects the client to be able to retrieve them by primary but instead expects the client to be able to retrieve them by primary
key fingerprint through some other keystore capable of (and key fingerprint through some other keystore capable of (and
responsible for) certificate update. responsible for) certificate refresh.
16. Privacy Considerations 14. Privacy Considerations
Keystores themselves raise a host of potential privacy concerns. Keystores themselves raise a host of potential privacy concerns.
Additional privacy concerns are raised by traffic to and from the Additional privacy concerns are raised by traffic to and from the
keystores. This section tries to outline some of the risks to the keystores. This section tries to outline some of the risks to the
privacy of people whose certificates are stored and redistributed in privacy of people whose certificates are stored and redistributed in
public keystores, as well as risks to the privacy of people who make public keystores, as well as risks to the privacy of people who make
use of the key stores for certificate lookup, certificate discovery, use of the key stores for certificate lookup, certificate discovery,
or certificate update. or certificate refresh.
16.1. Publishing Identity Information 14.1. Publishing Identity Information
Public OpenPGP keystores often distribute names or e-mail addresses Public OpenPGP keystores often distribute names or e-mail addresses
of people. Some people do not want their names or e-mail addresses of people. Some people do not want their names or e-mail addresses
distributed in a public keystore, or may change their minds about it distributed in a public keystore, or may change their minds about it
at some point. Append-only keystores are particularly problematic in at some point. Append-only keystores are particularly problematic in
that regard. The mitigation in Section 7.4 can help such users strip that regard. The mitigation in Section 7.4 can help such users strip
their details from keys that they control. However, if an OpenPGP their details from keys that they control. However, if an OpenPGP
certificate with their details is uploaded to a keystore, but is not certificate with their details is uploaded to a keystore, but is not
under their control, it's unclear what mechanisms can be used to under their control, it's unclear what mechanisms can be used to
remove the certificate that couldn't also be exploited to take down remove the certificate that couldn't also be exploited to take down
an otherwise valid certificate. an otherwise valid certificate.
Some jurisdictions may present additional legal risk for keystore Some jurisdictions may present additional legal risk for keystore
operators that distribute names or e-mail addresses of non-consenting operators that distribute names or e-mail addresses of non-consenting
parties. parties.
Updates-only keystores (Section 8) and user ID redacting keystores Refresh-only keystores (Section 8.1) and user ID redacting keystores
(Section 5.1) may reduce this particular privacy concern because they (Section 5.1) may reduce this particular privacy concern because they
distribute no user IDs at all. distribute no user IDs at all.
16.2. Social Graph 14.2. Social Graph
Third-party certifications effectively map out some sort of social Third-party certifications effectively map out some sort of social
graph. A certification asserts a statement of belief by the issuer graph. A certification asserts a statement of belief by the issuer
that the real-world party identified by the user ID is in control of that the real-world party identified by the user ID is in control of
the subject cryptographic key material. But those connections may be the subject cryptographic key material. But those connections may be
potentially sensitive, and some people may not want these maps built. potentially sensitive, and some people may not want these maps built.
A first-party-only keyserver (Section 9) avoids this privacy concern A first-party-only keyserver (Section 8.2) avoids this privacy
because it distributes no third-party privacy concern. concern because it distributes no third-party privacy concern.
First-party attested third-party certifications described in First-party attested third-party certifications described in
Section 10 are even more relevant edges in the social graph, because Section 8.3 are even more relevant edges in the social graph, because
their bidirectional nature suggests that both parties are aware of their bidirectional nature suggests that both parties are aware of
each other, and see some value in mutual association. each other, and see some value in mutual association.
16.3. Tracking Clients by Queries 14.3. Tracking Clients by Queries
Even without third-party certifications, the acts of certificate Even without third-party certifications, the acts of certificate
lookup, certificate discovery, and certificate update represent a lookup, certificate discovery, and certificate refresh represent a
potential privacy risk, because the keystore queried gets to learn potential privacy risk, because the keystore queried gets to learn
which user IDs (in the case of lookup) or which certificates (in the which user IDs (in the case of lookup) or which certificates (in the
case of update or discovery) the client is interested in. In the case of refresh or discovery) the client is interested in. In the
case of certificate update, if a client attempts to update all of its case of certificate refresh, if a client attempts to refresh all of
known certificates from the same keystore, that set is likely to be a its known certificates from the same keystore, that set is likely to
unique set, and therefore identifies the client. A keystore that be a unique set, and therefore identifies the client. A keystore
monitors the set of queries it receives might be able to profile or that monitors the set of queries it receives might be able to profile
track those clients who use it repeatedly. or track those clients who use it repeatedly.
A privacy-aware client which wants to to avoid such a tracking attack A privacy-aware client which wants to to avoid such a tracking attack
MAY try to perform certificate update from multiple different MAY try to perform certificate refresh from multiple different
keystores. To hide network location, a client making a network query keystores. To hide network location, a client making a network query
to a keystore SHOULD use an anonymity network like [TOR]. Tools like to a keystore SHOULD use an anonymity network like [TOR]. Tools like
[PARCIMONIE] are designed to facilitate this type of certificate [PARCIMONIE] are designed to facilitate this type of certificate
update. Such a client SHOULD also decline to use protocol features refresh. Such a client SHOULD also decline to use protocol features
that permit linkability across interactions with the same keystore, that permit linkability across interactions with the same keystore,
such as TLS session resumption, HTTP cookies, and so on. such as TLS session resumption, HTTP cookies, and so on.
Keystores which permit public access and want to protect the privacy Keystores which permit public access and want to protect the privacy
of their clients SHOULD NOT reject access from clients using [TOR] or of their clients SHOULD NOT reject access from clients using [TOR] or
comparable anonymity networks. Additionally, they SHOULD minimize comparable anonymity networks. Additionally, they SHOULD minimize
access logs they retain. access logs they retain.
Alternately, some keystores may distribute their entire contents to Alternately, some keystores may distribute their entire contents to
any interested client, in what can be seen as the most trivial form any interested client, in what can be seen as the most trivial form
of private information retrieval. [DEBIAN-KEYRING] is one such of private information retrieval. [DEBIAN-KEYRING] is one such
example; its contents are distributed as an operating system package. example; its contents are distributed as an operating system package.
Clients can interrogate their local copy of such a keystore without Clients can interrogate their local copy of such a keystore without
exposing their queries to a third-party. exposing their queries to a third-party.
16.4. "Live" Certificate Validation Leaks Client Activity 14.4. "Live" Certificate Validation Leaks Client Activity
If a client relies on a keystore's certificate validation interface, If a client relies on a keystore's certificate validation interface,
or on the presence of a certificate in a keystore as a part of its or on the presence of a certificate in a keystore as a part of its
validation calculations, it's unclear how long the assertion from the validation calculations, it's unclear how long the assertion from the
keystore is or should be considered to hold. One seemingly simple keystore is or should be considered to hold. One seemingly simple
approach is to simply query the keystore's validation interface each approach is to simply query the keystore's validation interface each
time that the client needs to validate the certificate. time that the client needs to validate the certificate.
This "live" validation approach poses a quandary to the client in the This "live" validation approach poses a quandary to the client in the
event that the keystore is unavailable. How should in interpret the event that the keystore is unavailable. How should in interpret the
"unknown" result? In addition, live validation reveals the client's "unknown" result? In addition, live validation reveals the client's
activity to the keystore with fine precision. activity to the keystore with fine precision.
A privacy-aware client that depends on keystores for certificate A privacy-aware client that depends on keystores for certificate
validation SHOULD NOT perform "live" certificate validation on each validation SHOULD NOT perform "live" certificate validation on each
use it makes of the certificate. Rather, it SHOULD cache the use it makes of the certificate. Rather, it SHOULD cache the
validation information for some period of time and make use of the validation information for some period of time and make use of the
cached copy where possible. If such a client does a regular cached copy where possible. If such a client does a regular
certificate update from the same keystore, it SHOULD also pre- certificate refresh from the same keystore, it SHOULD also pre-
emptively query the keystore for certificate validation at the same emptively query the keystore for certificate validation at the same
time. time.
Choosing the appropriate time intervals for this kind of caching has Choosing the appropriate time intervals for this kind of caching has
implications for the windows of risk for the client that might use a implications for the windows of risk for the client that might use a
revoked certificate. Defining an appropriate schedule to make this revoked certificate. Defining an appropriate schedule to make this
tradeoff is beyond the scope of this document. tradeoff is beyond the scope of this document.
16.5. Certificate Discovery Leaks Client Activity 14.5. Certificate Discovery Leaks Client Activity
The act of doing certificate discovery on unknown signatures offers a The act of doing certificate discovery on unknown signatures offers a
colluding keystore and remote peer a chance to track a client's colluding keystore and remote peer a chance to track a client's
consumption of a given signature. consumption of a given signature.
An attacker with access to keystore logs could sign a message with a An attacker with access to keystore logs could sign a message with a
unique key, and then watch the keystore activity to determine when a unique key, and then watch the keystore activity to determine when a
client consumes the signature. This is potentially a tracking or client consumes the signature. This is potentially a tracking or
"phone-home" situation. "phone-home" situation.
A signer that has no interest in this particular form of tracking can A signer that has no interest in this particular form of tracking can
mitigate this concern by shipping their certificate in-band, mitigate this concern by shipping their certificate in-band,
alongside the signature, as recommended in Section 13.3. alongside the signature, as recommended in Section 11.3.
A privacy-aware client MAY insist on in-band certificates by A privacy-aware client MAY insist on in-band certificates by
declining to use any certificate discovery interface at all, and declining to use any certificate discovery interface at all, and
treat a bare signature by an unknown certificate as an invalid treat a bare signature by an unknown certificate as an invalid
signature. signature.
16.6. Certificate Update Leaks Client Activity 14.6. Certificate Refresh Leaks Client Activity
The act of doing certificate update itself reveals some information The act of doing certificate refresh itself reveals some information
that the client is interested in a given certificate and how it may that the client is interested in a given certificate and how it may
have changed since the last time the client updated it, or since it have changed since the last time the client refreshed it, or since it
was first received by the client. was first received by the client.
This is essentially the same privacy problem presented by OCSP This is essentially the same privacy problem presented by OCSP
[RFC6960] in the X.509 world. In the online world of TLS, this [RFC6960] in the X.509 world. In the online world of TLS, this
privacy leak is mitigated by the CertificateStatus TLS handshake privacy leak is mitigated by the CertificateStatus TLS handshake
extension ([RFC4366]), a.k.a. "OCSP stapling". There is no extension ([RFC4366]), a.k.a. "OCSP stapling". There is no
comparable solution for the store-and-forward or non-online scenarios comparable solution for the store-and-forward or non-online scenarios
where OpenPGP is often found. where OpenPGP is often found.
Privacy-aware clients MAY prefer to access update interfaces from Privacy-aware clients MAY prefer to access refresh interfaces from
anonymity-preserving networks like [TOR] to obscure where they are on anonymity-preserving networks like [TOR] to obscure where they are on
the network, but if the certificate being updated is known to be used the network, but if the certificate being refreshed is known to be
only by a single client that may not help. used only by a single client that may not help.
Privacy-aware clients MAY prefer to stage their certificate updates Privacy-aware clients MAY prefer to stage their certificate refreshes
over time, but longer delays imply greater windows of vulnerability over time, but longer delays imply greater windows of vulnerability
for use of an already-revoked certificate. This strategy also does for use of an already-revoked certificate. This strategy also does
not help when a previously-unknown certificate is encountered in-band not help when a previously-unknown certificate is encountered in-band
(see Section 13.3), and the OpenPGP client wants to evaluate it for (see Section 11.3), and the OpenPGP client wants to evaluate it for
use in the immediate context. use in the immediate context.
16.7. Distinct Keystore Interfaces Leak Client Context and Intent 14.7. Distinct Keystore Interfaces Leak Client Context and Intent
The distinct keystore interfaces documented in Section 3 offer subtly The distinct keystore interfaces documented in Section 3 offer subtly
different semantics, and are used by a reasonable keystore client at different semantics, and are used by a reasonable keystore client at
different times. A keystore that offers distinct discovery and different times. A keystore that offers distinct discovery and
update interfaces may infer that a client visiting the update refresh interfaces may infer that a client visiting the refresh
interface already knows about the certificate in question, or that a interface already knows about the certificate in question, or that a
client visiting the discovery interface is in the process of client visiting the discovery interface is in the process of
verifying a signature from a certificate it has not seen before. verifying a signature from a certificate it has not seen before.
HKP itself ([I-D.shaw-openpgp-hkp]) conflates these two interfaces - HKP itself ([I-D.shaw-openpgp-hkp]) conflates these two interfaces -
the same HKP query is be used to perform both discovery and update the same HKP query is be used to perform both discovery and refresh
(though implementations like [SKS] are not at all abuse-resistant for (though implementations like [SKS] are not at all abuse-resistant for
either use), which may obscure the context and intent of the client either use), which may obscure the context and intent of the client
from the keystore somewhat. from the keystore somewhat.
A privacy-aware client that can afford the additional bandwidth and A privacy-aware client that can afford the additional bandwidth and
complexity MAY use the keystore's discovery interface for both update complexity MAY use the keystore's discovery interface for both
and discovery, since the discovery interface is a proper superset of refresh and discovery, since the discovery interface is a proper
the update interface. superset of the refresh interface.
16.8. Cleartext Queries 14.8. Cleartext Queries
If access to the keystore happens over observable channels (e.g., If access to the keystore happens over observable channels (e.g.,
cleartext connections over the Internet), then a passive network cleartext connections over the Internet), then a passive network
monitor could perform the same type profiling or tracking attack monitor could perform the same type profiling or tracking attack
against clients of the keystore described in Section 16.3. Keystores against clients of the keystore described in Section 14.3. Keystores
which offer network access SHOULD provide encrypted transport. which offer network access SHOULD provide encrypted transport.
16.9. Traffic Analysis 14.9. Traffic Analysis
Even if a keystore offers encrypted transport, the size of queries Even if a keystore offers encrypted transport, the size of queries
and responses may provide effective identification of the specific and responses may provide effective identification of the specific
certificates fetched during lookup, discovery, or update, leaving certificates fetched during lookup, discovery, or refresh, leaving
open the types of tracking attacks described in Section 16.3. open the types of tracking attacks described in Section 14.3.
Clients of keystores SHOULD pad their queries to increase the size of Clients of keystores SHOULD pad their queries to increase the size of
the anonymity set. And keystores SHOULD pad their responses. the anonymity set. And keystores SHOULD pad their responses.
The appropriate size of padding to effectively anonymize traffic to The appropriate size of padding to effectively anonymize traffic to
and from keystores is likely to be mechanism- and cohort-specific. and from keystores is likely to be mechanism- and cohort-specific.
For example, padding for keystores accessed via the DNS ([RFC7929] For example, padding for keystores accessed via the DNS ([RFC7929]
may use different padding strategies that padding for keystores may use different padding strategies that padding for keystores
accessed over WKD ([I-D.koch-openpgp-webkey-service]), which may in accessed over WKD ([I-D.koch-openpgp-webkey-service]), which may in
turn be different from keystores accessed over HKPS turn be different from keystores accessed over HKPS
([I-D.shaw-openpgp-hkp]). A keystore which only accepts user IDs ([I-D.shaw-openpgp-hkp]). A keystore which only accepts user IDs
within a specific domain (e.g., Section 4.3) or which uses custom within a specific domain (e.g., Section 4.3) or which uses custom
process (Section 6.4) for verification might have different padding process (Section 6.4) for verification might have different padding
criteria than a keystore that serves the general public. criteria than a keystore that serves the general public.
Specific padding policies or mechanisms are out of scope for this Specific padding policies or mechanisms are out of scope for this
document. document.
17. User Considerations 15. User Considerations
Section 10.2 describes some outstanding work that needs to be done to Section 8.3.1 describes some outstanding work that needs to be done
help users understand how to produce and distribute a third-party- to help users understand how to produce and distribute a third-party-
certified OpenPGP certificate to an abuse-resistant keystore. certified OpenPGP certificate to an abuse-resistant keystore.
Additionally, some keystores present directly user-facing Additionally, some keystores present directly user-facing
affordances. For example, [SKS] keyservers typically offer forms and affordances. For example, [SKS] keyservers typically offer forms and
listings that can be viewed directly in a web browser. Such a listings that can be viewed directly in a web browser. Such a
keystore SHOULD be as clear as possible about what abuse mitigations keystore SHOULD be as clear as possible about what abuse mitigations
it takes (or does not take), to avoid user confusion. it takes (or does not take), to avoid user confusion.
Keystores which do not expect to be used directly as part of a Keystores which do not expect to be used directly as part of a
certificate validation calculation SHOULD advise clients as certificate validation calculation SHOULD advise clients as
skipping to change at page 47, line 26 skipping to change at page 52, line 22
treat the keyserver web interfaces as authoritative. That is, users treat the keyserver web interfaces as authoritative. That is, users
act as though the keyserver network offers some type of certificate act as though the keyserver network offers some type of certificate
validation. Unfortunately, The developer and implementor communities validation. Unfortunately, The developer and implementor communities
explicitly disavow any authoritative role in the ecosystem, and the explicitly disavow any authoritative role in the ecosystem, and the
implementations attempt very few mitigations against abuse, implementations attempt very few mitigations against abuse,
permitting redistribution of even cryptographically invalid OpenPGP permitting redistribution of even cryptographically invalid OpenPGP
packets. Clearer warnings to end users might reduce this kind of packets. Clearer warnings to end users might reduce this kind of
misperception. Or the community could encourage the removal of misperception. Or the community could encourage the removal of
frequently misinterpreted user interfaces entirely. frequently misinterpreted user interfaces entirely.
18. IANA Considerations 16. IANA Considerations
This document asks IANA to register two entries in the OpenPGP This document asks IANA to register two entries in the OpenPGP
Notation IETF namespace, both with a reference to this document: Notation IETF namespace, both with a reference to this document:
o the "ksok" notation is defined in Section 10. o the "first-party-attestation" notation is defined in Section 8.3.
o the "uidhash" notation is defined in Section 5.1.4. o the "uidhash" notation is defined in Section 5.1.4.
19. Document Considerations 17. Document Considerations
[ RFC Editor: please remove this section before publication ] [ RFC Editor: please remove this section before publication ]
This document is currently edited as markdown. Minor editorial This document is currently edited as markdown. Minor editorial
changes can be suggested via merge requests at changes can be suggested via merge requests at
https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore or by https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore or by
e-mail to the author. Please direct all significant commentary to e-mail to the author. Please direct all significant commentary to
the public IETF OpenPGP mailing list: openpgp@ietf.org the public IETF OpenPGP mailing list: openpgp@ietf.org
19.1. Document History 17.1. Document History
substantive changes bewteen -03 and -04:
o change "certificate update" to "certificate refresh" for clarity
o relax first-party-attested third-party certification constraints
at the suggestion of Valodim
o introduce "primary key sovereignty" concept explicitly
o describe how to distribute and consume attestation revocations
o introduce augmentation to TPK for third-party certification
revocation distribution
substantive changes between -02 and -03: substantive changes between -02 and -03:
o new sections: o new sections:
* Keystore Interfaces * Keystore Interfaces
* Keystore Client Best Practices * Keystore Client Best Practices
* Certificate Generation and Management Best Practices * Certificate Generation and Management Best Practices
o rename "certificate discovery" to "certificate lookup" o rename "certificate discovery" to "certificate lookup"
o redefine "certificate discovery" to refer to lookup by signing o redefine "certificate discovery" to refer to lookup by signing
(sub)key (sub)key
o new attack: fingerprint flooding o new attack: fingerprint flooding
skipping to change at page 49, line 30 skipping to change at page 54, line 41
o documented Updates-Only Keystores o documented Updates-Only Keystores
o consider three different kinds of flooding o consider three different kinds of flooding
o deeper discussion of privacy considerations o deeper discussion of privacy considerations
o better documentation of Reason for Revocation o better documentation of Reason for Revocation
o document user ID conventions o document user ID conventions
20. Acknowledgements 18. Acknowledgements
This document is the result of years of operational experience and This document is the result of years of operational experience and
observation, as well as conversations with many different people - observation, as well as conversations with many different people -
users, implementors, keystore operators, etc. A non-exhaustive list users, implementors, keystore operators, etc. A non-exhaustive list
of people who have contributed ideas or nuance to this document of people who have contributed ideas or nuance to this document
specifically includes: specifically includes:
o Antoine Beaupre o Antoine Beaupre
o ilf o ilf
skipping to change at page 49, line 41 skipping to change at page 55, line 4
This document is the result of years of operational experience and This document is the result of years of operational experience and
observation, as well as conversations with many different people - observation, as well as conversations with many different people -
users, implementors, keystore operators, etc. A non-exhaustive list users, implementors, keystore operators, etc. A non-exhaustive list
of people who have contributed ideas or nuance to this document of people who have contributed ideas or nuance to this document
specifically includes: specifically includes:
o Antoine Beaupre o Antoine Beaupre
o ilf o ilf
o Jamie McClelland o Jamie McClelland
o Jonathan McDowell o Jonathan McDowell
o Justus Winter o Justus Winter
o Marcus Brinkmann o Marcus Brinkmann
o Micah Lee o Micah Lee
o Neal Walfield o Neal Walfield
o Phil Pennock o Phil Pennock
o Philihp Busby o Philihp Busby
o vedaal o vedaal
o Vincent Breitmoser o Vincent Breitmoser
o Wiktor Kwapisiewicz o Wiktor Kwapisiewicz
21. References 19. References
21.1. Normative References 19.1. Normative References
[I-D.ietf-openpgp-rfc4880bis] [I-D.ietf-openpgp-rfc4880bis]
Koch, W., carlson, b., Tse, R., and D. Atkins, "OpenPGP Koch, W., carlson, b., Tse, R., and D. Atkins, "OpenPGP
Message Format", draft-ietf-openpgp-rfc4880bis-06 (work in Message Format", draft-ietf-openpgp-rfc4880bis-07 (work in
progress), November 2018. progress), May 2019.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, DOI 10.17487/RFC2047, November 1996, RFC 2047, DOI 10.17487/RFC2047, November 1996,
<https://www.rfc-editor.org/info/rfc2047>. <https://www.rfc-editor.org/info/rfc2047>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007, DOI 10.17487/RFC4880, November 2007,
<https://www.rfc-editor.org/info/rfc4880>. <https://www.rfc-editor.org/info/rfc4880>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
21.2. Informative References 19.2. Informative References
[AUTOCRYPT] [AUTOCRYPT]
Breitmoser, V., Krekel, H., and D. Gillmor, "Autocrypt - Breitmoser, V., Krekel, H., and D. Gillmor, "Autocrypt -
Convenient End-to-End Encryption for E-Mail", n.d., Convenient End-to-End Encryption for E-Mail", n.d.,
<https://autocrypt.org/>. <https://autocrypt.org/>.
[BITCOIN] "Bitcoin", n.d., <https://bitcoin.org/>. [BITCOIN] "Bitcoin", n.d., <https://bitcoin.org/>.
[CONIKS] Felten, E., Freedman, M., Melara, M., Blankstein, A., and [CONIKS] Felten, E., Freedman, M., Melara, M., Blankstein, A., and
J. Bonneau, "CONIKS Key Management System", n.d., J. Bonneau, "CONIKS Key Management System", n.d.,
<https://coniks.cs.princeton.edu/>. <https://coniks.cs.princeton.edu/>.
[DEBIAN-KEYRING] [DEBIAN-KEYRING]
McDowell, J., "Debian Keyring", n.d., McDowell, J., "Debian Keyring", n.d.,
<https://keyring.debian.org/>. <https://keyring.debian.org/>.
[GnuPG] Koch, W., "Using the GNU Privacy Guard", n.d., [GnuPG] Koch, W., "Using the GNU Privacy Guard", April 2019,
<https://www.gnupg.org/documentation/manuals/gnupg.pdf>. <https://www.gnupg.org/documentation/manuals/gnupg.pdf>.
[I-D.koch-openpgp-webkey-service] [I-D.koch-openpgp-webkey-service]
Koch, W., "OpenPGP Web Key Directory", draft-koch-openpgp- Koch, W., "OpenPGP Web Key Directory", draft-koch-openpgp-
webkey-service-07 (work in progress), November 2018. webkey-service-08 (work in progress), May 2019.
[I-D.mccain-keylist] [I-D.mccain-keylist]
McCain, R., Lee, M., and N. Welch, "Distributing OpenPGP McCain, R., Lee, M., and N. Welch, "Distributing OpenPGP
Key Fingerprints with Signed Keylist Subscriptions", Key Fingerprints with Signed Keylist Subscriptions",
draft-mccain-keylist-04 (work in progress), March 2019. draft-mccain-keylist-04 (work in progress), March 2019.
[I-D.shaw-openpgp-hkp] [I-D.shaw-openpgp-hkp]
Shaw, D., "The OpenPGP HTTP Keyserver Protocol (HKP)", Shaw, D., "The OpenPGP HTTP Keyserver Protocol (HKP)",
draft-shaw-openpgp-hkp-00 (work in progress), March 2003. draft-shaw-openpgp-hkp-00 (work in progress), March 2003.
 End of changes. 189 change blocks. 
339 lines changed or deleted 593 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/