< draft-dkg-openpgp-abuse-resistant-keystore-01.txt   draft-dkg-openpgp-abuse-resistant-keystore-02.txt >
openpgp D. Gillmor openpgp D. Gillmor
Internet-Draft ACLU Internet-Draft ACLU
Intended status: Informational April 06, 2019 Intended status: Informational April 15, 2019
Expires: October 8, 2019 Expires: October 17, 2019
Abuse-Resistant OpenPGP Keystores Abuse-Resistant OpenPGP Keystores
draft-dkg-openpgp-abuse-resistant-keystore-01 draft-dkg-openpgp-abuse-resistant-keystore-02
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 any third-party can add certifications with any Unfortunately, since many keystores permit any third-party to add a
content to any OpenPGP certificate, the assembled/merged form of a certification with any content to any OpenPGP certificate, the
certificate can become unwieldy or undistributable. assembled/merged form of a certificate can become unwieldy or
undistributable. Furthermore, keystores that are searched by user ID
can be made unusable for specific names or addresses by public
submission of bogus data. And finally, keystores open to public
submission can also face simple resource exhaustion from flooding
with bogus submissions, or legal or other risks from uploads of toxic
data.
This draft documents techniques that an archive of OpenPGP This draft documents techniques that an archive of OpenPGP
certificates can use to mitigate the impact of these various forms of certificates can use to mitigate the impact of these various attacks.
flooding attacks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 8, 2019. This Internet-Draft will expire on October 17, 2019.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Certificate Flooding . . . . . . . . . . . . . . . . . . 6 2.1. Certificate Flooding . . . . . . . . . . . . . . . . . . 7
2.2. User ID Flooding . . . . . . . . . . . . . . . . . . . . 6 2.2. User ID Flooding . . . . . . . . . . . . . . . . . . . . 7
2.3. Keystore Flooding . . . . . . . . . . . . . . . . . . . . 7 2.3. Keystore Flooding . . . . . . . . . . . . . . . . . . . . 7
3. Simple Mitigations . . . . . . . . . . . . . . . . . . . . . 7 3. Toxic Data . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Decline Large Packets . . . . . . . . . . . . . . . . . . 7 4. Simple Mitigations . . . . . . . . . . . . . . . . . . . . . 8
3.2. Enforce Strict User IDs . . . . . . . . . . . . . . . . . 8 4.1. Decline Large Packets . . . . . . . . . . . . . . . . . . 8
3.3. Scoped User IDs . . . . . . . . . . . . . . . . . . . . . 8 4.2. Enforce Strict User IDs . . . . . . . . . . . . . . . . . 9
3.4. Strip or Standardize Unhashed Subpackets . . . . . . . . 8 4.3. Scoped User IDs . . . . . . . . . . . . . . . . . . . . . 9
3.5. Decline User Attributes . . . . . . . . . . . . . . . . . 9 4.4. Strip or Standardize Unhashed Subpackets . . . . . . . . 9
3.6. Decline Non-exportable Certifications . . . . . . . . . . 9 4.5. Decline User Attributes . . . . . . . . . . . . . . . . . 10
3.7. Decline Data From the Future . . . . . . . . . . . . . . 9 4.6. Decline Non-exportable Certifications . . . . . . . . . . 10
3.8. Accept Only Profiled Certifications . . . . . . . . . . . 9 4.7. Decline Data From the Future . . . . . . . . . . . . . . 10
3.9. Accept Only Certificates Issued by Designated Authorities 10 4.8. Accept Only Profiled Certifications . . . . . . . . . . . 10
3.10. Decline Packets by Blocklist . . . . . . . . . . . . . . 10 4.9. Accept Only Certificates Issued by Designated Authorities 11
4. Contextual Mitigations . . . . . . . . . . . . . . . . . . . 11 4.10. Decline Packets by Blocklist . . . . . . . . . . . . . . 11
4.1. Accept Only Cryptographically-verifiable Certifications . 11 5. Retrieval-time Mitigations . . . . . . . . . . . . . . . . . 12
4.2. Accept Only Certificates Issued by Known Certificates . . 11 5.1. Redacting User IDs . . . . . . . . . . . . . . . . . . . 12
4.3. Rate-limit Submissions by IP Address . . . . . . . . . . 12 5.1.1. Certificate Update with Redacted User IDs . . . . . . 12
4.4. Accept Certiifcates Based on Exterior Process . . . . . . 12 5.1.2. Certificate Discovery with Redacted User IDs . . . . 13
4.5. Accept Certificates by E-mail Validation . . . . . . . . 12 5.1.3. Hinting Redacted User IDs . . . . . . . . . . . . . . 13
5. Non-append-only mitigations . . . . . . . . . . . . . . . . . 13 5.1.4. User ID Recovery by Client Brute Force . . . . . . . 14
5.1. Drop Superseded Signatures . . . . . . . . . . . . . . . 13 6. Contextual Mitigations . . . . . . . . . . . . . . . . . . . 14
5.2. Drop Expired Signatures . . . . . . . . . . . . . . . . . 14 6.1. Accept Only Cryptographically-verifiable Certifications . 14
5.3. Drop Dangling User IDs, User Attributes, and Subkeys . . 14 6.2. Accept Only Certificates Issued by Known Certificates . . 14
5.4. Drop All Other Elements of a Directly-Revoked Certificate 14 6.3. Rate-limit Submissions by IP Address . . . . . . . . . . 15
5.5. Implicit Expiration Date . . . . . . . . . . . . . . . . 15 6.4. Accept Certificates Based on Exterior Process . . . . . . 15
6. Updates-only Keystores . . . . . . . . . . . . . . . . . . . 15 6.5. Accept Certificates by E-mail Validation . . . . . . . . 15
7. First-party-only Keystores . . . . . . . . . . . . . . . . . 16
8. First-party-attested Third-party Certifications . . . . . . . 16
8.1. Key Server Preferences "No-modify" . . . . . . . . . . . 17
8.2. Client Interactions . . . . . . . . . . . . . . . . . . . 18
9. Side Effects and Ecosystem Impacts . . . . . . . . . . . . . 18
9.1. Designated Revoker . . . . . . . . . . . . . . . . . . . 18
9.2. Certification-capable Subkeys . . . . . . . . . . . . . . 18
9.3. Assessing Certificates in the Past . . . . . . . . . . . 19
10. OpenPGP details . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Revocations . . . . . . . . . . . . . . . . . . . . . . 19
10.2. User ID Conventions . . . . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
12.1. Publishing Identity Information . . . . . . . . . . . . 22
12.2. Social Graph . . . . . . . . . . . . . . . . . . . . . . 22
12.3. Tracking Clients by Queries . . . . . . . . . . . . . . 22
12.4. Cleartext Queries . . . . . . . . . . . . . . . . . . . 23
12.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 23
13. User Considerations . . . . . . . . . . . . . . . . . . . . . 24
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
15. Document Considerations . . . . . . . . . . . . . . . . . . . 24
15.1. Document History . . . . . . . . . . . . . . . . . . . . 24
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
17.1. Normative References . . . . . . . . . . . . . . . . . . 25
17.2. Informative References . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 7. Non-append-only mitigations . . . . . . . . . . . . . . . . . 16
7.1. Drop Superseded Signatures . . . . . . . . . . . . . . . 16
7.2. Drop Expired Signatures . . . . . . . . . . . . . . . . . 17
7.3. Drop Dangling User IDs, User Attributes, and Subkeys . . 17
7.4. Drop All Other Elements of a Directly-Revoked Certificate 17
7.5. Implicit Expiration Date . . . . . . . . . . . . . . . . 18
8. Updates-only Keystores . . . . . . . . . . . . . . . . . . . 18
9. First-party-only Keystores . . . . . . . . . . . . . . . . . 19
9.1. First-party-only Without User IDs . . . . . . . . . . . . 19
10. First-party-attested Third-party Certifications . . . . . . . 19
10.1. Key Server Preferences "No-modify" . . . . . . . . . . . 21
10.2. Client Interactions . . . . . . . . . . . . . . . . . . 21
11. Side Effects and Ecosystem Impacts . . . . . . . . . . . . . 21
11.1. Designated Revoker . . . . . . . . . . . . . . . . . . . 21
11.2. Certification-capable Subkeys . . . . . . . . . . . . . 22
11.3. Assessing Certificates in the Past . . . . . . . . . . . 22
11.3.1. Point-in-time Certificate Evaluation . . . . . . . . 22
11.3.2. Signature Verification and Non-append-only Keystores 23
11.4. Global Append-only Ledgers ("Blockchain") . . . . . . . 23
11.5. Certificate Discovery for Identity Monitoring . . . . . 24
12. OpenPGP details . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Revocations . . . . . . . . . . . . . . . . . . . . . . 25
12.2. User ID Conventions . . . . . . . . . . . . . . . . . . 26
13. Security Considerations . . . . . . . . . . . . . . . . . . . 27
13.1. Tension Between Unrestricted Uploads and Certificate
Discovery . . . . . . . . . . . . . . . . . . . . . . . 27
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
14.1. Publishing Identity Information . . . . . . . . . . . . 28
14.2. Social Graph . . . . . . . . . . . . . . . . . . . . . . 28
14.3. Tracking Clients by Queries . . . . . . . . . . . . . . 28
14.4. Cleartext Queries . . . . . . . . . . . . . . . . . . . 29
14.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 29
15. User Considerations . . . . . . . . . . . . . . . . . . . . . 30
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
17. Document Considerations . . . . . . . . . . . . . . . . . . . 30
17.1. Document History . . . . . . . . . . . . . . . . . . . . 31
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
19.1. Normative References . . . . . . . . . . . . . . . . . . 32
19.2. Informative References . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34
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.
1.2. Terminology 1.2. Terminology
skipping to change at page 4, line 26 skipping to change at page 4, line 47
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 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
hold, or update the certificates. hold, or update the certificates.
o "Certificate discovery" is the process whereby a user retrieves an o "Certificate discovery" is the process whereby a user retrieves an
OpenPGP certificate based on user ID (see Section 10.2). A user OpenPGP certificate based on user ID (see Section 12.2). A user
attempting to discover a certificate from a keystore will search attempting to discover a certificate from a keystore will search
for a substring of the known user IDs, most typically an e-mail for a substring of the known user IDs, most typically an e-mail
address if the user ID is an [RFC5322] name-addr or addr-spec. address if the user ID is an [RFC5322] name-addr or addr-spec.
Some certificate discovery mechanisms look for an exact match on Some certificate discovery mechanisms look for an exact match on
the known user IDs. [I-D.koch-openpgp-webkey-service] and the known user IDs. [I-D.koch-openpgp-webkey-service] and
[I-D.shaw-openpgp-hkp] both offer certificate discovery [I-D.shaw-openpgp-hkp] both offer certificate discovery
mechanisms. mechanisms.
o "Certificate validation" is the process whereby a user decides o "Certificate validation" is the process whereby a user decides
whether a given user ID in an OpenPGP certificate is acceptable. whether a given user ID in an OpenPGP certificate is acceptable.
skipping to change at page 5, line 25 skipping to change at page 5, line 47
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 discovery, keyserver is typically useful for certificate discovery,
certificate updates, and revocation information. They are certificate updates, and revocation information. They are
typically _not_ useful for certificate validation, since they make typically _not_ useful for certificate validation, since they make
no assertions about whether the identities in the certificates no assertions about whether the identities in the certificates
they server are accurate. As of the writing of this document, they server are accurate. As of the writing of this document,
[SKS] is the canonical synchronizing keyserver implementation, [SKS] is the canonical synchronizing keyserver implementation,
though other implementations exist. 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 possibly 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
discovery based on e-mail address and certificate validation (by discovery 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 revocation, since a certificate could be certificate update or revocation, since a certificate could be
simply replaced by an adversary who also has access to the e-mail simply replaced by an adversary who also has access to the e-mail
address in question. [MAILVELOPE-KEYSERVER] is an example of such address in question. [MAILVELOPE-KEYSERVER] is an example of such
skipping to change at page 6, line 11 skipping to change at page 6, line 32
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 10.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 flooding attacks by malicious submitters. to a range of attacks by malicious submitters.
This section describes three distinct flooding attacks that public This section describes four distinct attacks that public keystores
keystores should consider. should consider.
The rest of the document describes some mitigations that can be used The rest of the document describes some mitigations that can be used
by keystores that are concerned about these problems but want to by keystores that are concerned about these problems but want to
continue to offer some level of service for certificate discovery, continue to offer some level of service for certificate discovery,
certificate update, or certificate validation. certificate update, 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
skipping to change at page 7, line 39 skipping to change at page 8, line 16
The keystore itself can become difficult to operate if the total The keystore itself can become difficult to operate if the total
quantity of data is too large, and if it is a synchronizing quantity of data is too large, and if it is a synchronizing
keyserver, then the quantities of data may impose unsustainable keyserver, then the quantities of data may impose unsustainable
bandwidth costs on the operator as well. bandwidth costs on the operator as well.
Effectively mitigating against keystore flooding requires either Effectively mitigating against keystore flooding requires either
abandoning the append-only property that some keystores prefer, or abandoning the append-only property that some keystores prefer, or
imposing very strict controls on initial ingestion. imposing very strict controls on initial ingestion.
3. Simple Mitigations 3. Toxic Data
Like any large public dataset, it's possible that a keystore ends up
hosting some content that is legally actionable in some
jurisdictions, including libel, child pornography, material under
copyright or other "intellectual property" controls, blasphemy, hate
speech, etc.
A public keystore that accepts and redistributes arbitrary content
may face risk due to uploads of toxic data.
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.
3.1. Decline Large Packets 4.1. Decline Large Packets
While [RFC4880] permits OpenPGP packet sizes of arbitrary length, While [RFC4880] permits OpenPGP packet sizes of arbitrary length,
OpenPGP certificates rarely need to be so large. An abuse-resistant OpenPGP certificates rarely need to be so large. An abuse-resistant
keystore SHOULD reject any OpenPGP packet larger than 8383 octets. keystore SHOULD reject any OpenPGP packet larger than 8383 octets.
(This cutoff is chosen because it guarantees that the packet size can (This cutoff is chosen because it guarantees that the packet size can
be represented as a one- or two-octet [RFC4880] "New Format Packet be represented as a one- or two-octet [RFC4880] "New Format Packet
Length", but it could be reduced further) Length", but it could be reduced further)
This may cause problems for user attribute packets that contain large This may cause problems for user attribute packets that contain large
images, but it's not clear that these images are concretely useful in images, but it's not clear that these images are concretely useful in
any context. Some keystores MAY extend this limit for user attribute any context. Some keystores MAY extend this limit for user attribute
packets specifically, but SHOULD NOT allow even user attributes packets specifically, but SHOULD NOT allow even user attributes
packets larger than 65536 octets. packets larger than 65536 octets.
3.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". spec, or a URL like "ssh://host.example.org".
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.
3.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
certificates whose user IDs refer to e-mail addresses within the DNS certificates whose user IDs refer to e-mail addresses within the DNS
zone. [I-D.koch-openpgp-webkey-service] similarly aims to restrict zone. [I-D.koch-openpgp-webkey-service] similarly aims to restrict
publication to certificates relevant to the specific e-mail domain. publication to certificates relevant to the specific e-mail domain.
3.4. Strip or Standardize Unhashed Subpackets 4.4. Strip or Standardize Unhashed Subpackets
[RFC4880] signature packets contain an "unhashed" block of [RFC4880] signature packets contain an "unhashed" block of
subpackets. These subpackets are not covered by any cryptographic subpackets. These subpackets are not covered by any cryptographic
signature, so they are ripe for abuse. signature, so they are ripe for abuse.
An abuse-resistant keysetore SHOULD strip out all unhashed An abuse-resistant keysetore SHOULD strip out all unhashed
subpackets. subpackets.
Note that some certifications only identify the issuer of the Note that some certifications only identify the issuer of the
certification by an unhashed Issuer ID subpacket. If a certification by an unhashed Issuer ID subpacket. If a
certification's hashed subpacket section has no Issuer ID or Issuer certification's hashed subpacket section has no Issuer ID or Issuer
Fingerprint (see [I-D.ietf-openpgp-rfc4880bis]) subpacket, then an Fingerprint (see [I-D.ietf-openpgp-rfc4880bis]) subpacket, then an
abuse-resistant keystore that has cryptographically validated the abuse-resistant keystore that has cryptographically validated the
certification SHOULD make the unhashed subpackets contain only a certification SHOULD make the unhashed subpackets contain only a
single subpacket. That subpacket should be of type Issuer single subpacket. That subpacket should be of type Issuer
Fingerprint, and should contain the fingerprint of the issuer. Fingerprint, and should contain the fingerprint of the issuer.
A special exception may be made for unhashed subpackets in a third- A special exception may be made for unhashed subpackets in a third-
party certification that contain attestations from the certificate's party certification that contain attestations from the certificate's
primary key as described in Section 8. primary key as described in Section 10.
3.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
that cover them. that cover them.
3.6. Decline Non-exportable Certifications 4.6. Decline Non-exportable Certifications
An abuse-resistant keystore MUST NOT accept any certification that An abuse-resistant keystore MUST NOT accept any certification that
has the "Exportable Certification" subpacket present and set to 0. has the "Exportable Certification" subpacket present and set to 0.
While most keystore clients will not upload these "local" While most keystore clients will not upload these "local"
certifications anyway, a reasonable public keystore that wants to certifications anyway, a reasonable public keystore that wants to
minimize data has no business storing or distributing these minimize data has no business storing or distributing these
certifications. certifications.
3.7. Decline Data From the Future 4.7. Decline Data From the Future
Many OpenPGP packets have time-of-creation timestamps in them. An Many OpenPGP packets have time-of-creation timestamps in them. An
abuse-resistant keystore with a functional real-time clock MAY decide abuse-resistant keystore with a functional real-time clock MAY decide
to only accept packets whose time-of-creation is in the future. to only accept packets whose time-of-creation is in the past.
Note that some OpenPGP implementations may pre-generate OpenPGP Note that some OpenPGP implementations may pre-generate OpenPGP
material intended for use only in some future window (e.g. "Here is material intended for use only in some future window (e.g. "Here is
the certificate we plan to use to sign our software next year; do not the certificate we plan to use to sign our software next year; do not
accept signatures from it until then."), and may use modified time- accept signatures from it until then."), and may use modified time-
of-creation timestamps to try to acheive that purpose. This material of-creation timestamps to try to achieve that purpose. This material
would not be distributable ahead of time by an abuse-resistant would not be distributable ahead of time by an abuse-resistant
keystore that adopts this mitigation. keystore that adopts this mitigation.
3.8. Accept Only Profiled Certifications 4.8. Accept Only Profiled Certifications
An aggressively abuse-resistant keystore MAY decide to only accept An aggressively abuse-resistant keystore MAY decide to only accept
certifications that meet a specific profile. For example, it MAY certifications that meet a specific profile. For example, it MAY
reject certifications with unknown subpacket types, unknown reject certifications with unknown subpacket types, unknown
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 5). a keystore is no longer append-only (please see Section 7).
3.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.
If no user IDs are certified by designated authority, such a keystore If no user IDs are certified by designated authority, such a keystore
SHOULD decline the certificate and its primary key entirely. Such a SHOULD decline the certificate and its primary key entirely. Such a
skipping to change at page 10, line 34 skipping to change at page 11, line 30
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 5). such a keystore may no longer be append-only (please see Section 7).
3.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 (please see
Section 5). Section 7).
Some keystores may choose to apply a blocklist only at distribution Some keystores may choose to apply a blocklist only at retrieval time
time and not apply it at input 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. 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
or politically contentious. There needs to be a clear policy about or politically contentious as it may describe data that is toxic
how it is managed, whether by delegation to specific decision-makers, (Section 3) in one community or jurisdiction but not another. There
or explicit tests. Furthermore, the existence of even a well- needs to be a clear policy about how it is managed, whether by
intentioned blocklist may be an "attractive nuisance," drawing the delegation to specific decision-makers, or explicit tests.
interest of would-be censors or other attacker interested in Furthermore, the existence of even a well-intentioned blocklist may
controlling the ecosystem reliant on the keystore in question. be an "attractive nuisance," drawing the interest of would-be censors
or other attacker interested in controlling the ecosystem reliant on
the keystore in question.
4. Contextual Mitigations 5. Retrieval-time Mitigations
Most of the abuse mitigations described in this document are
described as being applied at certificate ingestion time. It's also
possible to apply the same mitigations when a certificate is
retrieved from the keystore (that is, during certificate update or
certificate discovery). Applying an abuse mitigation at retrieval
time may help a client defend against a user ID flooding
(Section 2.2) or certificate flooding (Section 2.1) attack. However,
only mitigations applied at ingestion time are able to mitigate
keystore flooding attacks (Section 2.3).
Some mitigations (like the non-append-only mitigations described in
Section 7) may be applied as filters at retrieval time, while still
allowing access to the (potentially much larger) unfiltered dataset
associated given certificate or user ID via a distinct interface.
The rest of this section documents a specific mitigation that is
applied only at retrieval time.
5.1. Redacting User IDs
Some abuse-resistant keystores may accept and store user IDs but
decline to redistribute some or all of them, while still distributing
the certifications that cover those redacted user IDs. This draft
refers to such a keystore as a "user ID redacting" keystore.
The certificates distributed by such a keystore are technically
invalid [RFC4880] "transferable public keys", because they lack a
user ID packet, and the distributed certifications cannot be
cryptographically validated independently. However, an OpenPGP
implementation that already knows the user IDs associated with a
given primary key will be capable of associating each certification
with the correct user ID by trial signature verification.
5.1.1. Certificate Update with Redacted User IDs
A user ID redacting keystore is useful for certificate update by a
client that already knows the user ID it expects to see associated
with the certificate. For example, a client that knows a given
certificate currently has two specific user IDs could access the
keystore to learn that one of the user IDs has been revoked, without
any other client learning the user IDs directly from the keystore.
5.1.2. Certificate Discovery with Redacted User IDs
It's possible (though non-intuitive) to use a user ID redacting
keystore for certificate discovery. Since the keystore retains (but
does not distribute) the user IDs, they can be used to select
certificates in response to a search. The OpenPGP certificates sent
back in response to the search will not contain the user IDs, but a
client that knows the full user ID they are searching for will be
able to verify the returned certifications.
Certificate discovery from a user ID redacting keystore works better
for certificate discovery by exact user ID match than it does for
substring match, because a client that discovers a substring match
may not be able to reconstruct the redacted user ID.
However, without some additional restrictions on which certifications
are redistributed (whether the user ID is redacted or not),
certificate discovery can be flooded (see Section 13.1).
5.1.3. Hinting Redacted User IDs
To ensure that the distributed certificate is at least structurally a
valid [RFC4880] transferable public key, a user ID redacting keystore
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.
This two-octet replacement user ID packet ("\xb4\x00") is called the
"unstated user ID".
To facilitate clients that match certifications with specific user
IDs, a user ID redacting keystore MAY insert a non-hashed notation
subpacket into the certification. The notation will have a name of
"uidhash", with 0x80 ("human-readable") flag unset. The value of
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.
A certificate update client which receives such a certification after
the "unstated user ID" SHOULD compute the SHA-256 digest of all user
IDs it knows about on the certificate, and compare the result with
the contents of the "uidhash" notation to decide which user ID to try
to validate the certification against.
5.1.4. User ID Recovery by Client Brute Force
User ID redaction is at best an imperfect process. Even if a
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
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
commonly-used hostnames
6. Contextual Mitigations
Some mitigations make the acceptance or rejection of packets Some mitigations make the acceptance or rejection of packets
contingent on data that is already in the keystore or the keystore's contingent on data that is already in the keystore or the keystore's
developing knowledge about the world. This means that, depending on developing knowledge about the world. This means that, depending on
the order that the keystore encounters the various material, or how the order that the keystore encounters the various material, or how
it discovers the material, the final set of material retained and it discovers the material, the final set of material retained and
distributed by the keystore might be different. distributed by the keystore might be different.
While this isn't necessarily bad, it may be a surprising property for While this isn't necessarily bad, it may be a surprising property for
some users of keystores. some users of keystores.
4.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.
4.2. Accept Only Certificates Issued by Known Certificates 6.2. Accept Only Certificates Issued by Known Certificates
This is an extension of Section 3.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
effectively a policy decision. effectively a policy decision.
This mitigation measure may fail due to a compromise of any secret This mitigation measure may fail due to a compromise of any secret
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 3.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.
4.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.
This requires that the keystore maintain state about recent This requires that the keystore maintain state about recent
submissions over time and address. It may also be problematic for submissions over time and address. It may also be problematic for
users who appear to share an IP address from the vantage of the users who appear to share an IP address from the vantage of the
keystore, including those beind a NAT, using a VPN, or accessing the keystore, including those behind a NAT, using a VPN, or accessing the
keystore via Tor. keystore via Tor.
4.4. Accept Certiifcates Based on Exterior Process 6.4. Accept Certificates Based on Exterior Process
Some public keystores resist abuse by explicitly filtering OpenPGP Some public keystores resist abuse by explicitly filtering OpenPGP
material based on a set of external processes. For example, material based on a set of external processes. For example,
[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.
4.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. In some cases, the e-mail itself is encrypted to an
encryption-capable key found in the proposed certificate. If the encryption-capable key found in the proposed certificate. If the
keyholder triggers the confirmation mechanism, then the keystore keyholder triggers the confirmation mechanism, then the keystore
accepts the certificate. accepts the certificate.
Some e-mail validating keystores MAY choose to distribute
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
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.
5. 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 any keystore that expects to be append-only (for
example, some keyserver synchronization techniques may expect this example, some keyserver synchronization techniques may expect this
property to hold). property to hold).
Furthermore, keystores that drop old data, or certifications that are Furthermore, keystores that drop old data (e.g., superseded
superseded may make it difficult or impossible for their users to certifications) may make it difficult or impossible for their users
reason about the validity of signatures that were made in the past. to reason about the validity of signatures that were made in the
See Section 9.3 for more considerations. past. See Section 11.3 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. cryptographic validation MAY omit these mitigations. Alternately, a
keystore may omit these mitigations at certificate ingestion time,
but apply these mitigations at retrieval time (during certificate
update or discovery), and offer a more verbose (non-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
is superseded by a later signature, revoked signatures, is superseded by a later signature, revoked signatures,
and signatures issued by keys that are not present on the and signatures issued by keys that are not present on the
keyring. keyring.
5.1. Drop Superseded Signatures 7.1. Drop Superseded Signatures
An abuse-resistant keystore SHOULD drop all signature packets that An abuse-resistant keystore SHOULD drop all signature packets that
are explicitly superseded. For example, there's no reason to retain are explicitly superseded. For example, there's no reason to retain
or distribute a self-sig by key K over User ID U from 2017 if the or distribute a self-sig by key K over User ID U from 2017 if the
keystore have a cryptographically-valid self-sig over <K,U> from keystore have a cryptographically-valid self-sig over <K,U> from
2019. 2019.
Note that this covers both certifications and signatures over Note that this covers both certifications and signatures over
subkeys, as both of these kinds of signature packets may be subkeys, as both of these kinds of signature packets may be
superseded. superseded.
Getting this right requires a nuanced understanding of subtleties in Getting this right requires a nuanced understanding of subtleties in
[RFC4880] related to timing and revocation. [RFC4880] related to timing and revocation.
5.2. Drop Expired Signatures 7.2. Drop Expired Signatures
If a signature packet is known to only be valid in the past, there is If a signature packet is known to only be valid in the past, there is
no reason to distribute it further. An abuse-resistant keystore with no reason to distribute it further. An abuse-resistant keystore with
access to a functionally real-time clock SHOULD drop all access to a functionally real-time clock SHOULD drop all
certifications and subkey signature packets with an expiration date certifications and subkey signature packets with an expiration date
in the past. in the past.
Note that this assumes that the keystore and its clients all have Note that this assumes that the keystore and its clients all have
roughly-synchronized clocks. If that is not the case, then there roughly-synchronized clocks. If that is not the case, then there
will be many other problems! will be many other problems!
5.3. Drop Dangling User IDs, User Attributes, and Subkeys 7.3. Drop Dangling User IDs, User Attributes, and Subkeys
If enough signature packets are dropped, it's possible that some of If enough signature packets are dropped, it's possible that some of
the things that those signature packets cover are no longer valid. the things that those signature packets cover are no longer valid.
An abuse-resistant keystore which has dropped all certifications that An abuse-resistant keystore which has dropped all certifications that
cover a User ID SHOULD also drop the User ID packet. cover a User ID SHOULD also drop the User ID packet.
Note that a User ID that becomes invalid due to revocation MUST NOT Note that a User ID that becomes invalid due to revocation MUST NOT
be dropped, because the User ID's revocation signature itself remains be dropped, because the User ID's revocation signature itself remains
valid, and needs to be distributed. valid, and needs to be distributed.
A primary key with no User IDs and no subkeys and no revocations MAY A primary key with no User IDs and no subkeys and no revocations MAY
itself also be removed from distribution, though note that the itself also be removed from distribution, though note that the
removal of a primary key may make it impossible to cryptographically removal of a primary key may make it impossible to cryptographically
validate other certifications held by the keystore. validate other certifications held by the keystore.
5.4. Drop All Other Elements of a Directly-Revoked Certificate 7.4. Drop All Other Elements of a Directly-Revoked Certificate
If the primary key of a certiifcate is revoked via a direct key If the primary key of a certificate is revoked via a direct key
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 10.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
keystore SHOULD retain the signature that sorts earliest based on a keystore SHOULD retain the signature that sorts earliest based on a
binary string comparison of the direct key revocation signature binary string comparison of the direct key revocation signature
packet itself. packet itself.
5.5. Implicit Expiration Date 7.5. Implicit Expiration Date
In combination with some of the dropping mitigations above, a In combination with some of the dropping mitigations above, a
particularly aggressive abuse-resistant keystore MAY choose an particularly aggressive abuse-resistant keystore MAY choose an
implicit expiration date for all signature packets. For example, a implicit expiration date for all signature packets. For example, a
signature packet that claims no expiration could be treated by the signature packet that claims no expiration could be treated by the
keystore as expiring 3 years after issuance. This would permit the keystore as expiring 3 years after issuance. This would permit the
keystore to eject old packets on a rolling basis. keystore to eject old packets on a rolling basis.
FIXME: it's not clear what should happen with signature packets FIXME: it's not clear what should happen with signature packets
marked with an explicit expiration that is longer than implicit marked with an explicit expiration that is longer than implicit
maximum. Should it be capped to the implicit date, or accepted? maximum. Should it be capped to the implicit date, or accepted?
Warning: This idea is pretty radical, and it's not clear what it Warning: This idea is pretty radical, and it's not clear what it
would do to an ecosystem that depends on such a keystore. It would do to an ecosystem that depends on such a keystore. It
probably needs more thinking. probably needs more thinking.
6. Updates-only Keystores 8. Updates-only Keystores
In addition to the mitigations above, some keystores may resist abuse In addition to the mitigations above, some keystores may resist abuse
by declining to accept any user IDs or certifications whatsoever. 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 signatures, cryptographically-validated binding signatures (and cross signatures,
where necessary). where necessary).
Clients of an updates-only keystore cannot possibly use the keystore Clients of an updates-only keystore cannot possibly use the keystore
for certificate discovery, because there are no user IDs to match. for certificate discovery, because there are no user IDs to match.
However, they can use it for certificate update, as it's possible to However, they can use it for certificate update, as it's possible to
ship revocations (which are direct key signatures), new subkeys, 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 implemenations do not implement direct Note that many popular OpenPGP implementations do not implement
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. updates-only keystore.
Certificates shipped by an updates-only keystore are technically Certificates shipped by an updates-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.
7. First-party-only Keystores 9. First-party-only Keystores
Slightly more permissive than the updates-only keystore described in Slightly more permissive than the updates-only keystore described in
Section 6 is a keystore that also permits user IDs and their self- Section 8 is a keystore that also permits user IDs and their self-
sigs. 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 solves the problem of abusive bloating attacks on This effectively solves the problem of abusive bloating attacks on
any certificate, because the only party who can make a certificate any certificate, because the only party who can make a certificate
overly large is the holder of the secret corresponding to the primary overly large is the holder of the secret corresponding to the primary
key itself. key itself.
However, 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 discovery of third-party people who rely on the keystore for discovery of third-party
certifications. Section 8 attempts to address this lack. certifications. Section 10 attempts to address this lack.
8. First-party-attested Third-party Certifications 9.1. First-party-only Without User IDs
It is possible to operate an updates-only keystore that also declines
to redistribute user IDs (Section 5.1). This defends against
concerns about publishing identifiable information, while enabling
full certificate update for those 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 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 third-party certifications as long as the first-party has signed off
on the specific third-party certification. on the specific third-party certification.
An abuse-resistant keystore SHOULD only accept a third-party An abuse-resistant keystore SHOULD only accept a third-party
certification if it meets the following criteria: certification if it meets the following criteria:
o The third-party certification MUST be cryptographically valid. o The third-party certification MUST be cryptographically valid.
Note that this means that the keystore needs to know the primary Note that this means that the keystore needs to know the primary
skipping to change at page 17, line 47 skipping to change at page 21, line 10
o the third-party has made the identity assertion o the third-party has made the identity assertion
o the first-party has confirmed that they're OK with the third-party o the first-party has confirmed that they're OK with the third-party
certification being distributed by any keystore. certification being distributed by any keystore.
FIXME: it's not clear whether the "ksok" notification is necessary - FIXME: it's not clear whether the "ksok" notification is necessary -
it's in place to avoid some accidental confusion with any other use it's in place to avoid some accidental confusion with any other use
of the Third-Party Confirmation signature packet type, but the author of the Third-Party Confirmation signature packet type, but the author
does not know of any such use that might collide. does not know of any such use that might collide.
8.1. Key Server Preferences "No-modify" 10.1. Key Server Preferences "No-modify"
[RFC4880] defines "Key Server Preferences" with a "No-modify" bit. [RFC4880] defines "Key Server Preferences" with a "No-modify" bit.
That bit has never been respected by any keyserver implementation That bit has never been respected by any keyserver implementation
that the author is aware of. This section effectively asks an abuse- that the author is aware of. An abuse-resistant keystore following
resistant keystore to treat that bit as always set, whether it is Section 10 effectively treats that bit as always set, whether it is
present in the certificate or not. present in the certificate or not.
8.2. Client Interactions 10.2. Client Interactions
The multi-stage layer of creating such an attestation (certificate Creating such an attestation requires multiple steps by different
creation by the first-party, certification by the third-party, parties, each of which is blocked by all prior steps:
attestation by the first-party, then handoff to the keystore) may
represent a usability obstacle to a user who needs a third-party- o The first-party creates the certificate, and transfers it to the
certified OpenPGP certificate. third party.
o The third-party certifies it, and transfers their certification
back to the first party.
o The first party attests to the third party's certification.
o Finally, the first party then transfers the compound certificate
to the keystore.
The complexity and length of such a sequence may represent a
usability obstacle to a user who needs a third-party-certified
OpenPGP certificate.
No current OpenPGP client can easily create the attestions described No current OpenPGP client can easily create the attestions described
in this section. More implementation work needs to be done to make in this section. More implementation work needs to be done to make
it easy (and understandable) for a user to perform this kind of it easy (and understandable) for a user to perform this kind of
attestation. attestation.
9. Side Effects and Ecosystem Impacts 11. Side Effects and Ecosystem Impacts
9.1. Designated Revoker 11.1. Designated Revoker
A first-party-only keystore as described in Section 7 might decline A first-party-only keystore as described in Section 9 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.
9.2. Certification-capable Subkeys 11.2. 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 5) 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.
9.3. Assessing Certificates in the Past 11.3. 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
download time. download time.
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.
When evaluating a certificate at a time T in the past, one approach 11.3.1. Point-in-time Certificate Evaluation
is to discard all packets with a creation time later than T, and then
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
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
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 evaluator SHOULD NOT ignore "hard" OpenPGP key However, any such evaluation MUST NOT ignore "hard" OpenPGP key
revocations, regardless of their creation date. (see Section 10.1). revocations, regardless of their creation date. (see Section 12.1).
If a non-append-only keystore (Section 5) has dropped superseded 11.3.2. Signature Verification and Non-append-only Keystores
(Section 5.1) or expired (Section 5.2) certifications, it's possible
If a non-append-only keystore (Section 7) has dropped superseded
(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. Such a certificate would be invalid according to was made. Such a certificate would be invalid according to
[RFC4880]. [RFC4880], and consequently verification of any signature .
10. OpenPGP details However, there is a simple mitigation: anyone distributing a
signature (e.g. a software archive) should ship the contemporary
signing certificate alongside the signature. If the distributor does
this, then the verifier can perform a certificate update (to learn
about revocations) against any preferred keystore, including non-
append-only keystores, merging what it learns into the distributed
contemporary certificate.
Then the signature verifier can follow the certificate evaluation
process outlined in Section 11.3.1, using the merged certificate.
11.4. Global Append-only Ledgers ("Blockchain")
The append-only aspect of some OpenPGP keystores encourages a user 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
they know about. An unfaithful "append-only" keystore could abuse
the trust in a number of ways, including withholding revocation
certificates, offering different sets of certificates to different
clients doing key discovery, and so on.
However, the most widely used append-only OpenPGP keystore, the [SKS]
keyserver pool, offers no cryptographically verifiable guarantees
that it will actually remain append-only. Users of the pool have
traditionally relied on its distributed nature, and the presumption
that coordination across a wide range of administrators would make it
difficult for the pool to reliably lie or omit data. However, the
endpoint most commonly used by clients to access the network is
"hkps://hkps.pool.sks-keyservers.net", the default for [GnuPG]. That
endpoint is increasingly consolidated, and currently consists of
hosts operated by only two distinct administrators, increasing the
risk of potential misuse.
Offering cryptographic assurances that a keystore could remain
append-only is an appealing prospect to defend against these kinds of
attack. Many popular schemes for providing such assurances are known
as "blockchain" technologies, or global append-only ledgers.
With X.509 certificates, we have a semi-functional Certificate
Transparency ([RFC6962], or "CT") ecosystem that is intended to
document and preserve evidence of (mis)issuance by well-known
certificate authorities (CAs), which implements a type of global
append-only ledger. While the CT infrastructure remains vulnerable
to certain combinations of colluding actors, it has helped to
identify and sanction some failing CAs.
Like other global append-only ledgers, CT itself is primarily a
detection mechanism, and has no enforcement regime. If a widely-used
CA were identified by certificate transparency to be untrustworthy,
the rest of the ecosystem still needs to figure out how to impose
sanctions or apply a remedy, which may or may not be possible.
CT also has privacy implications - the certificates published in the
CT logs are visible to everyone, for the lifetime of the log.
For spam abatement, CT logs decline all X.509 certificates except
those issued by certain CAs (those in popular browser "root stores").
This is an example of the strategy outlined in Section 4.9).
Additional projects that provide some aspects of global append-only
ledgers that try to address some of the concerns described here
include [KEY-TRANSPARENCY] and [CONIKS], though they are not specific
to OpenPGP. Both of these systems are dependent on servers operated
by identity providers, however. And both offer the ability to detect
a misbehaving identity provider, but no specific enforcement or
recovery strategies against such an actor.
It's conceivable that a keystore could piggyback on the CT logs or
other blockchain/ledger mechanisms like [BITCOIN] to store
irrevocable pieces of data (such as revocation certificates).
Further work is needed to describe how to do this in an effective and
performant way.
11.5. Certificate Discovery for Identity Monitoring
A typical use case for certificate discovery is a user looking for a
certificate in order to be able to encrypt an outbound message
intended for a given e-mail address, but this is not the only use
case.
Another use caes is when the party in control of a particular
identity wants to determine whether anyone else is claiming that
identity. That is, a client in control of the secret key material
associated with a particular certificate with user ID X might search
a keystore for all certificates matching X in order to discover
whether any other certificates claim it.
This is an important safeguard as part of the ledger-based detection
mechanisms described in Section 11.4, but may also be useful for
keystores in general.
However, identity monitoring against a keystore that does not defend
against user ID flooding (Section 2.2) is expensive and potentially
of limited value. In particular, a malicious actor with a
certificate which duplicates a given User ID could flood the keystore
with similar certificates, hiding whichever one is in malicious use.
Since such a keystore is not considered authoritative by any
reasonable client for the user ID in question, this attack forces the
identity-monitoring defender to spend arbitrary resources fetching
and evaluating each certificate in the flood, without knowing which
certificate other clients might be evaluating.
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.
10.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 20, line 34 skipping to change at page 26, 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.
10.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 21, line 4 skipping to change at page 26, line 36
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>
But a growing number of OpenPGP certificates contain user IDs that But a growing number of OpenPGP certificates contain user IDs that
are instead a raw [RFC5322] addr-spec, omitting the display-name and are instead a raw [RFC5322] addr-spec, omitting the display-name and
the angle brackets entirely, like so: the angle brackets entirely, like so:
alice@example.org alice@example.org
Some certificates have user IDs that are simply "normal" human names Some certificates have user IDs that are simply "normal" human names
(perhaps display-name in [RFC5322] jargon, though not necessarily (perhaps display-name in [RFC5322] jargon, though not necessarily
conforming to a specific ABNF). For example: conforming to a specific ABNF). For example:
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
11. 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.3), or against flooding attacks on the keystore itself (see Section 2.3), 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 9.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)
13.1. Tension Between Unrestricted Uploads and Certificate Discovery
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 discovery. certificate uploads and permitting effective certificate discovery.
If a keystore accepts arbitrary certificate uploads for If a keystore accepts arbitrary certificate uploads for
redistribution, it appears to be vulnerable to user ID flooding redistribution, it appears to be vulnerable to user ID flooding
(Section 2.2), which makes it difficult or impossible to rely on for (Section 2.2), which makes it difficult or impossible to rely on for
certificate discovery. certificate discovery.
TODO (more security considerations) In the broader ecosystem, it may be necessary to use gated/controlled
certificate discovery mechanisms. For example, both
[I-D.koch-openpgp-webkey-service] and [RFC7929] enable the
administrator of a DNS domain to distribute certificates associated
with e-mail addresses within that domain, while excluding other
parties. As a rather different example, [I-D.mccain-keylist] offers
certificate discovery on the basis of interest - a client interested
in an organization can use that mechanism to learn what certificates
that organization thinks are worth knowing about, regardless of the
particular DNS domain. Note that this [I-D.mccain-keylist] does not
provide the certificates directly, but instead expects the client to
be able to retrieve them by certificate fingerprint through some
other keystore capable of (and responsible for) certificate update.
12. 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 discovery or certificate use of the key stores for certificate discovery or certificate
update. update.
TODO (more privacy considerations) TODO (more privacy considerations)
12.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 5.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.
An updates-only keyserver (Section 6) avoids this particular privacy Some jurisdictions may present additional legal risk for keystore
concern because it distributes no user IDs at all. operators that distribute names or e-mail addresses of non-consenting
parties.
12.2. Social Graph Updates-only keystores (Section 8) and user ID redacting keystores
(Section 5.1) may reduce this particular privacy concern because they
distribute no user IDs at all.
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 7) avoids this privacy concern A first-party-only keyserver (Section 9) avoids this privacy concern
because it distribues no third-party privacy concern. because it distribues no third-party privacy concern.
First-party attested third-party certifications described in First-party attested third-party certifications described in
Section 8 are even more relevant edges in the social graph, because Section 10 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.
12.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
discovery and certificate update represent a potential privacy risk, discovery and certificate update represent a potential privacy risk,
because the keystore queried gets to learn which user IDs (in the because the keystore queried gets to learn which user IDs (in the
case of discovery) or which certificates (in the case of update) the case of discovery) or which certificates (in the case of update) the
client is interested in. In the case of certificate update, if a client is interested in. In the case of certificate update, if a
client attempts to update all of its known certificates from the same client attempts to update all of its known certificates from the same
keystore, that set is likely to be a unique set, and therefore keystore, that set is likely to be a unique set, and therefore
identifies the client. A keystore that monitors the set of queries identifies the client. A keystore that monitors the set of queries
it receives might be able to profile or track those clients who use it receives might be able to profile or track those clients who use
skipping to change at page 23, line 23 skipping to change at page 29, line 30
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.
12.4. Cleartext Queries 14.4. 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 12.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.
12.5. Traffic Analysis 14.5. 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 discovery or update, leaving open the certificates fetched during discovery or update, leaving open the
types of tracking attacks described in Section 12.3. Clients of types of tracking attacks described in Section 14.3. Clients of
keystores SHOULD pad their queries to increase the size of the keystores SHOULD pad their queries to increase the size of the
anonymity set. And keystores SHOULD pad their responses. 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 3.3) or which uses custom within a specific domain (e.g., Section 4.3) or which uses custom
process (Section 4.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.
13. User Considerations 15. User Considerations
Section 8.2 describes some outstanding work that needs to be done to Section 10.2 describes some outstanding work that needs to be done to
help users understand how to produce and distribute a third-party- 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.
14. IANA Considerations Additionally, some keystores present directly user-facing
affordances. For example, [SKS] keyservers typically offer forms and
listings that can be viewed directly in a web browser. Such a
keystore SHOULD be as clear as possible about what abuse mitigations
it takes (or does not take), to avoid user confusion.
This document asks IANA to register the "ksok" notation name in the Experience with the [SKS] keyserver network shows that many users
OpenPGP Notation IETF namespace, with a reference to this document, treat the keyserver web interfaces as authoritative, even though the
as defined in Section 8. developer and implementor communities explicitly disavow any
authoritative role in the ecosystem, and the implementations attempt
very few mitigations against abuse, permitting republication of even
cryptographically invalid OpenPGP packets. Clearer warnings to end
users might reduce this kind of misperception. Or the community
could encourage the removal of frequently misinterpreted user
interfaces.
15. Document Considerations 16. IANA Considerations
This document asks IANA to register two entries in the OpenPGP
Notation IETF namespace, both with a reference to this document:
o the "ksok" notation is defined in Section 10.
o the "uidhash" notation is defined in Section 5.1.3.
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
15.1. Document History 17.1. Document History
substantive changes between -01 and -02:
o distinguish different forms of flooding attack
o distinguish toxic data as distinct from flooding
o retrieval-time mitigations
o user ID redaction
o references to related work (CT, keylist, CONIKS, key transparency,
ledgers/"blockchain", etc)
o more details about UI/UX
substantive changes between -00 and -01: substantive changes between -00 and -01:
o split out Contextual and Non-Append-Only mitigations o split out Contextual and Non-Append-Only mitigations
o documented several other mitigations, including: o documented several other mitigations, including:
* Decline Data From the Future * Decline Data From the Future
* Blocklist * Blocklist
skipping to change at page 25, line 4 skipping to change at page 31, line 47
* Known Certificates * Known Certificates
* Rate-Limiting * Rate-Limiting
* Scoped User IDs * Scoped User IDs
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
16. 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 contriubuted ideas or nuance to this document of people who have contriubuted ideas or nuance to this document
specifically includes: specifically includes:
o Antoine Beaupre o Antoine Beaupre
o ilf
o Jamie McClelland o Jamie McClelland
o Jonathan McDowell o Jonathan McDowell
o Justus Winter o Justus Winter
o Marcus Brinkmann
o Micah Lee
o Neal Walfield o Neal Walfield
o Phil Pennock
o vedaal o vedaal
o Vincent Breitmoser o Vincent Breitmoser
o Wiktor Kwapisiewicz o Wiktor Kwapisiewicz
17. References 19. References
17.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-06 (work in
progress), November 2018. progress), November 2018.
[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>.
17.2. Informative References 19.2. Informative References
[BITCOIN] "Bitcoin", n.d., <https://bitcoin.org/>.
[CONIKS] Felten, E., Freedman, M., Melara, M., Blankstein, A., and
J. Bonneau, "CONIKS Key Management System", n.d.,
<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", n.d.,
<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-07 (work in progress), November 2018.
[I-D.mccain-keylist]
McCain, R., Lee, M., and N. Welch, "Distributing OpenPGP
Key Fingerprints with Signed Keylist Subscriptions",
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.
[KEY-TRANSPARENCY]
Belvin, G. and R. Hurst, "Key Transparency, a transparent
and secure way to look up public keys", n.d.,
<https://keytransparency.org/>.
[MAILVELOPE-KEYSERVER] [MAILVELOPE-KEYSERVER]
Oberndoerfer, T., "Mailvelope Keyserver", n.d., Oberndoerfer, T., "Mailvelope Keyserver", n.d.,
<https://github.com/mailvelope/keyserver/>. <https://github.com/mailvelope/keyserver/>.
[MONKEYSPHERE] [MONKEYSPHERE]
Gillmor, D. and J. Rollins, "Monkeysphere", n.d., Gillmor, D. and J. Rollins, "Monkeysphere", n.d.,
<https://web.monkeysphere.info/>. <https://web.monkeysphere.info/>.
[PARCIMONIE] [PARCIMONIE]
Intrigeri, ., "Parcimonie", n.d., Intrigeri, ., "Parcimonie", n.d.,
skipping to change at page 26, line 49 skipping to change at page 34, line 24
[PGP-GLOBAL-DIRECTORY] [PGP-GLOBAL-DIRECTORY]
Symantec Corporation, "PGP Global Directory Key Symantec Corporation, "PGP Global Directory Key
Verification Policy", 2011, Verification Policy", 2011,
<https://keyserver.pgp.com/vkd/ <https://keyserver.pgp.com/vkd/
VKDVerificationPGPCom.html>. VKDVerificationPGPCom.html>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/info/rfc6962>.
[RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities
(DANE) Bindings for OpenPGP", RFC 7929, (DANE) Bindings for OpenPGP", RFC 7929,
DOI 10.17487/RFC7929, August 2016, DOI 10.17487/RFC7929, August 2016,
<https://www.rfc-editor.org/info/rfc7929>. <https://www.rfc-editor.org/info/rfc7929>.
[SKS] Pennock, P., "SKS Keyserver Documentation", March 2018, [SKS] Minsky, Y., Fiskerstrand, K., and P. Pennock, "SKS
Keyserver Documentation", March 2018,
<https://bitbucket.org/skskeyserver/sks-keyserver/wiki/ <https://bitbucket.org/skskeyserver/sks-keyserver/wiki/
Home>. Home>.
[TOR] "The Tor Project", n.d., <https://www.torproject.org/>. [TOR] "The Tor Project", n.d., <https://www.torproject.org/>.
Author's Address Author's Address
Daniel Kahn Gillmor Daniel Kahn Gillmor
American Civil Liberties Union American Civil Liberties Union
125 Broad St. 125 Broad St.
 End of changes. 117 change blocks. 
185 lines changed or deleted 534 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/