idnits 2.17.1 draft-dkg-openpgp-abuse-resistant-keystore-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1137 has weird spacing: '...ct (by remov...' == Line 1140 has weird spacing: '..., this remov...' == Line 1141 has weird spacing: '... any signat...' == Line 1142 has weird spacing: '...revoked signa...' -- The document date (April 19, 2019) is 1833 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-openpgp-rfc4880bis-06 == Outdated reference: A later version (-17) exists of draft-koch-openpgp-webkey-service-07 == Outdated reference: A later version (-05) exists of draft-mccain-keylist-04 -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 openpgp D. Gillmor 3 Internet-Draft ACLU 4 Intended status: Informational April 19, 2019 5 Expires: October 21, 2019 7 Abuse-Resistant OpenPGP Keystores 8 draft-dkg-openpgp-abuse-resistant-keystore-03 10 Abstract 12 OpenPGP transferable public keys are composite certificates, made up 13 of primary keys, direct key signatures, user IDs, identity 14 certifications ("signature packets"), subkeys, and so on. They are 15 often assembled by merging multiple certificates that all share the 16 same primary key, and are distributed in public keystores. 18 Unfortunately, since many keystores permit any third-party to add a 19 certification with any content to any OpenPGP certificate, the 20 assembled/merged form of a certificate can become unwieldy or 21 undistributable. Furthermore, keystores that are searched by user ID 22 or fingerprint can be made unusable for specific searches by public 23 submission of bogus certificates. And finally, keystores open to 24 public submission can also face simple resource exhaustion from 25 flooding with bogus submissions, or legal or other risks from uploads 26 of toxic data. 28 This draft documents techniques that an archive of OpenPGP 29 certificates can use to mitigate the impact of these various attacks, 30 and the implications of these concerns and mitigations for the rest 31 of the OpenPGP ecosystem. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 21, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 71 2.1. Certificate Flooding . . . . . . . . . . . . . . . . . . 7 72 2.2. User ID Flooding . . . . . . . . . . . . . . . . . . . . 8 73 2.3. Fingerprint Flooding . . . . . . . . . . . . . . . . . . 8 74 2.4. Keystore Flooding . . . . . . . . . . . . . . . . . . . . 9 75 2.5. Toxic Data . . . . . . . . . . . . . . . . . . . . . . . 9 76 3. Keystore Interfaces . . . . . . . . . . . . . . . . . . . . . 9 77 3.1. Certificate Update . . . . . . . . . . . . . . . . . . . 10 78 3.2. Certificate Discovery . . . . . . . . . . . . . . . . . . 10 79 3.3. Certificate Lookup . . . . . . . . . . . . . . . . . . . 11 80 3.3.1. Full User ID Lookup . . . . . . . . . . . . . . . . . 11 81 3.3.2. E-mail Address Lookup . . . . . . . . . . . . . . . . 12 82 3.3.3. Other Lookup Mechanisms . . . . . . . . . . . . . . . 12 83 3.4. Certificate Validation . . . . . . . . . . . . . . . . . 12 84 3.5. Certificate Submission . . . . . . . . . . . . . . . . . 14 85 4. Simple Mitigations . . . . . . . . . . . . . . . . . . . . . 14 86 4.1. Decline Large Packets . . . . . . . . . . . . . . . . . . 14 87 4.2. Enforce Strict User IDs . . . . . . . . . . . . . . . . . 15 88 4.3. Scoped User IDs . . . . . . . . . . . . . . . . . . . . . 15 89 4.4. Strip or Standardize Unhashed Subpackets . . . . . . . . 15 90 4.4.1. Issuer Fingerprint . . . . . . . . . . . . . . . . . 15 91 4.4.2. Cross-sigs . . . . . . . . . . . . . . . . . . . . . 15 92 4.4.3. First-party Attestations . . . . . . . . . . . . . . 16 93 4.5. Decline User Attributes . . . . . . . . . . . . . . . . . 16 94 4.6. Decline Non-exportable Certifications . . . . . . . . . . 16 95 4.7. Decline Data From the Future . . . . . . . . . . . . . . 16 96 4.8. Accept Only Profiled Certifications . . . . . . . . . . . 16 97 4.9. Accept Only Certificates Issued by Designated Authorities 17 98 4.10. Decline Packets by Blocklist . . . . . . . . . . . . . . 17 99 5. Retrieval-time Mitigations . . . . . . . . . . . . . . . . . 18 100 5.1. Redacting User IDs . . . . . . . . . . . . . . . . . . . 19 101 5.1.1. Certificate Update with Redacted User IDs . . . . . . 19 102 5.1.2. Certificate Discovery with Redacted User IDs . . . . 19 103 5.1.3. Certificate Lookup with Redacted User IDs . . . . . . 20 104 5.1.4. Hinting Redacted User IDs . . . . . . . . . . . . . . 20 105 5.1.5. User ID Recovery by Client Brute Force . . . . . . . 21 106 5.2. Primary-key Only Certificate Update . . . . . . . . . . . 21 107 5.3. Require Valid Cross-Sigs for Certificate Discovery . . . 21 108 6. Contextual Mitigations . . . . . . . . . . . . . . . . . . . 22 109 6.1. Accept Only Cryptographically-verifiable Certifications . 22 110 6.2. Accept Only Certificates Issued by Known Certificates . . 23 111 6.3. Rate-limit Submissions by IP Address . . . . . . . . . . 23 112 6.4. Accept Certificates Based on Exterior Process . . . . . . 23 113 6.5. Accept Certificates by E-mail Validation . . . . . . . . 24 114 7. Non-append-only mitigations . . . . . . . . . . . . . . . . . 24 115 7.1. Drop Superseded Signatures . . . . . . . . . . . . . . . 25 116 7.2. Drop Expired Signatures . . . . . . . . . . . . . . . . . 25 117 7.3. Drop Dangling User IDs, User Attributes, and Subkeys . . 25 118 7.4. Drop All Other Elements of a Directly-Revoked Certificate 26 119 7.5. Implicit Expiration Date . . . . . . . . . . . . . . . . 26 120 8. Updates-only Keystores . . . . . . . . . . . . . . . . . . . 27 121 9. First-party-only Keystores . . . . . . . . . . . . . . . . . 27 122 9.1. First-party-only Without User IDs . . . . . . . . . . . . 28 123 10. First-party-attested Third-party Certifications . . . . . . . 28 124 10.1. Key Server Preferences "No-modify" . . . . . . . . . . . 29 125 10.2. Client Interactions . . . . . . . . . . . . . . . . . . 30 126 11. Keystore Client Best Practices . . . . . . . . . . . . . . . 30 127 11.1. Use Constrained Keystores for Lookup . . . . . . . . . . 30 128 11.2. Normalize Addresses and User IDs for Lookup . . . . . . 30 129 11.3. Avoid Fuzzy Lookups . . . . . . . . . . . . . . . . . . 31 130 11.4. Prefer Full Fingerprint for Discovery and Update . . . . 31 131 11.5. Use Caution with Keystore-provided Validation . . . . . 31 132 12. Certificate Generation and Management Best Practices . . . . 32 133 12.1. Canonicalized E-Mail Addresses . . . . . . . . . . . . . 32 134 12.2. Normalized User IDs . . . . . . . . . . . . . . . . . . 32 135 12.3. Avoid Large User Attributes . . . . . . . . . . . . . . 32 136 12.4. Provide Cross-Sigs . . . . . . . . . . . . . . . . . . . 33 137 12.5. Provide Issuer Fingerprint Subpackets . . . . . . . . . 33 138 12.6. Put Cross-Sigs and Issuer Fingerprint in Hashed 139 Subpackets . . . . . . . . . . . . . . . . . . . . . . . 33 140 12.7. Submit Certificates to Restricted, Lookup-Capable 141 Keystores . . . . . . . . . . . . . . . . . . . . . . . 33 142 13. Side Effects and Ecosystem Impacts . . . . . . . . . . . . . 33 143 13.1. Designated Revoker . . . . . . . . . . . . . . . . . . . 33 144 13.2. Key IDs vs. Fingerprints in Certificate Discovery . . . 34 145 13.3. In-band Certificates . . . . . . . . . . . . . . . . . . 34 146 13.3.1. In-band Certificate Minimization and Validity . . . 35 147 13.4. Certification-capable Subkeys . . . . . . . . . . . . . 36 148 13.5. Assessing Certificates in the Past . . . . . . . . . . . 36 149 13.5.1. Point-in-time Certificate Evaluation . . . . . . . . 37 150 13.5.2. Signature Verification and Non-append-only Keystores 37 151 13.6. Global Append-only Ledgers ("Blockchain") . . . . . . . 37 152 13.7. Certificate Lookup for Identity Monitoring . . . . . . . 39 153 14. OpenPGP details . . . . . . . . . . . . . . . . . . . . . . . 39 154 14.1. Revocations . . . . . . . . . . . . . . . . . . . . . . 39 155 14.2. User ID Conventions . . . . . . . . . . . . . . . . . . 40 156 14.3. E-mail Address Canonicalization . . . . . . . . . . . . 41 157 14.3.1. Disallowing Non-UTF-8 Local Parts . . . . . . . . . 41 158 14.3.2. Domain Canonicalization . . . . . . . . . . . . . . 41 159 14.3.3. Local Part Canonicalization . . . . . . . . . . . . 41 160 15. Security Considerations . . . . . . . . . . . . . . . . . . . 41 161 15.1. Tension Between Unrestricted Uploads and Certificate 162 Lookup . . . . . . . . . . . . . . . . . . . . . . . . . 42 163 16. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42 164 16.1. Publishing Identity Information . . . . . . . . . . . . 42 165 16.2. Social Graph . . . . . . . . . . . . . . . . . . . . . . 43 166 16.3. Tracking Clients by Queries . . . . . . . . . . . . . . 43 167 16.4. "Live" Certificate Validation Leaks Client Activity . . 44 168 16.5. Certificate Discovery Leaks Client Activity . . . . . . 44 169 16.6. Certificate Update Leaks Client Activity . . . . . . . . 45 170 16.7. Distinct Keystore Interfaces Leak Client Context and 171 Intent . . . . . . . . . . . . . . . . . . . . . . . . . 45 172 16.8. Cleartext Queries . . . . . . . . . . . . . . . . . . . 46 173 16.9. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 46 174 17. User Considerations . . . . . . . . . . . . . . . . . . . . . 46 175 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 176 19. Document Considerations . . . . . . . . . . . . . . . . . . . 47 177 19.1. Document History . . . . . . . . . . . . . . . . . . . . 47 178 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 179 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 180 21.1. Normative References . . . . . . . . . . . . . . . . . . 50 181 21.2. Informative References . . . . . . . . . . . . . . . . . 50 182 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 52 184 1. Introduction 186 1.1. Requirements Language 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 190 "OPTIONAL" in this document are to be interpreted as described in BCP 191 14 [RFC2119] [RFC8174] when, and only when, they appear in all 192 capitals, as shown here. 194 1.2. Terminology 196 o "OpenPGP certificate" (or just "certificate") is used 197 interchangeably with [RFC4880]'s "Transferable Public Key". The 198 term "certificate" refers unambiguously to the entire composite 199 object, unlike "key", which might also be used to refer to a 200 primary key or subkey. 202 o An "identity certification" (or just "certification") is an 203 [RFC4880] signature packet that covers OpenPGP identity 204 information - that is, any signature packet of type 0x10, 0x11, 205 0x12, or 0x13. Certifications are said to (try to) "bind" a 206 primary key to a User ID. 208 o The primary key that makes the certification is known as the 209 "issuer". The primary key over which the certification is made is 210 known as the "subject". 212 o A "first-party certification" is issued by the primary key of a 213 certificate, and binds itself to a user ID in the certificate. 214 That is, the issuer is the same as the subject. This is sometimes 215 referred to as a "self-sig". 217 o A "third-party certification" is a made over a primary key and 218 user ID by some other certification-capable primary key. That is, 219 the issuer is different than the subject. (The elusive "second- 220 party" is presumed to be the verifier who is trying to interpret 221 the certificate) 223 o All subkeys are bound to the primary key with an [RFC4880] Subkey 224 Binding Signature. Some subkeys also reciprocate by binding 225 themselves back to the primary key with an [RFC4880] Primary Key 226 Binding Signature. The Primary Key Binding Signature is also 227 known as a "cross-signature" or "cross-sig". 229 o A "keystore" is any collection of OpenPGP certificates. Keystores 230 typically receive mergeable updates over the course of their 231 lifetime which might add to the set of OpenPGP certificates they 232 hold, or update the certificates. 234 o "Certificate validation" is the process whereby a user decides 235 whether a given user ID in an OpenPGP certificate is acceptable 236 for use. For example, if the certificate has a user ID of "Alice 237 " and the user wants to send an e-mail to 238 "alice@example.org", the mail user agent might want to ensure that 239 the certificate is valid for this e-mail address before encrypting 240 to it. Some clients may rely on specific keystores for 241 certificate validation, but some keystores (e.g., [SKS]) make no 242 assertions whatsoever about certificate validity, and others offer 243 only very subtle guarantees. See Section 3.4 for more details. 245 o "Certificate lookup" refers to the retrieval of a set of 246 certificates from a keystore based on the user ID or some 247 substring match of the user ID. See Section 3.3 for more details. 249 o "Certificate update" refers to retrieval of a certificate from a 250 keystore based on the fingerprint of the primary key. See 251 Section 3.1 for more details. 253 o "Certificate discovery" refers to the retrieval of a set of 254 certificates from a keystore based on the fingerprint or key ID of 255 any key in the certificate. See Section 3.2 for more details. 257 o A "keyserver" is a particular kind of keystore, typically a means 258 of publicly distributing OpenPGP certificates or updates to them. 259 Examples of keyserver software include [SKS] and 260 [MAILVELOPE-KEYSERVER]. One common HTTP interface for keyservers 261 is [I-D.shaw-openpgp-hkp]. 263 o A "synchronizing keyserver" is a keyserver which gossips with 264 other peers, and typically acts as an append-only log. Such a 265 keyserver is typically useful for certificate lookup, certificate 266 discovery, and certificate update (including revocation 267 information). They are typically _not_ useful for certificate 268 validation, since they make no assertions about whether the 269 identities in the certificates they server are accurate. As of 270 the writing of this document, [SKS] is the canonical synchronizing 271 keyserver implementation, though other implementations exist. 273 o An "e-mail validating keyserver" is a keyserver which attempts to 274 verify the identity in an OpenPGP certificate's user ID by 275 confirming access to the e-mail account, and possibly by 276 confirming access to the secret key. Some implementations permit 277 removal of a certificate by anyone who can prove access to the 278 e-mail address in question. They are useful for certificate 279 lookup based on e-mail address and certificate validation (by 280 users who trust the operator), but some may not be useful for 281 certificate update or certificate discovery, since a certificate 282 could be simply replaced by an adversary who also has access to 283 the e-mail address in question. [MAILVELOPE-KEYSERVER] is an 284 example of such a keyserver. 286 o "Cryptographic validity" refers to mathematical evidence that a 287 signature came from the secret key associated with the public key 288 it claims to come from. Note that a certification may be 289 cryptographically valid without the signed data being true (for 290 example, a given certificate with the user ID "Alice 291 " might not belong to the person who controls 292 the e-mail address "alice@example.org" even though the self-sig is 293 cryptographically valid). In particular, cryptographic validity 294 for user ID in a certificate is typically insufficient evidence 295 for certificate validation. Also note that knowledge of the 296 public key of the issuer is necessary to determine whether any 297 given signature is cryptographically valid. Some keyservers 298 perform cryptographic validation in some contexts. Other 299 keyservers (like [SKS]) perform no cryptographic validation 300 whatsoever. 302 o OpenPGP revocations can have "Reason for Revocation" (see 303 [RFC4880]), which can be either "soft" or "hard". The set of 304 "soft" reasons is: "Key is superseded" and "Key is retired and no 305 longer used". All other reasons (and revocations that do not 306 state a reason) are "hard" revocations. See Section 14.1 for more 307 detail. 309 2. Problem Statement 311 OpenPGP keystores that handle submissions from the public are subject 312 to a range of attacks by malicious submitters. 314 This section describes five distinct attacks that public keystores 315 should consider. 317 The rest of the document describes some mitigations that can be used 318 by keystores that are concerned about these problems but want to 319 continue to offer some level of service for certificate lookup, 320 certificate update, certificate discovery, or certificate validation. 322 2.1. Certificate Flooding 324 Many public keystores (including both the [SKS] keyserver network and 325 [MAILVELOPE-KEYSERVER]) allow anyone to attach arbitrary data (in the 326 form of third-party certifications) to any certificate, bloating that 327 certificate to the point of being impossible to effectively retrieve. 328 For example, some OpenPGP implementations simply refuse to process 329 certificates larger than a certain size. 331 This kind of Denial-of-Service attack makes it possible to make 332 someone else's certificate unretrievable from the keystore, 333 preventing certificate lookup, discovery, or update. In the case of 334 a revoked certificate that has been flooded, this potentially leaves 335 the client of the keystore with the compromised certificate in an 336 unrevoked state locally because it was unable to fetch the revocation 337 information. 339 Additionally, even without malice, OpenPGP certificates can 340 potentially grow without bound. 342 2.2. User ID Flooding 344 Public keystores that are used for certificate lookup may also be 345 vulnerable to attacks that flood the space of known user IDs. In 346 particular, if the keystore accepts arbitrary certificates from the 347 public and does no verification of the user IDs, then any client 348 searching for a given user ID may need to review and process an 349 effectively unbounded set of maliciously-submitted certificates to 350 find the non-malicious certificates they are looking for. 352 For example, if an attacker knows that a given system consults a 353 keystore looking for certificates which match the e-mail address 354 "alice@example.org", the attacker may upload hundreds or thousands of 355 certificates containing user IDs that match that address. Even if 356 those certificates would not be accepted by a client (e.g., because 357 they were not certified by a known-good authority), the client 358 typically still has to wade through all of them in order to find the 359 non-malicious certificates. 361 If the keystore does not offer a lookup interface at all (that is, if 362 clients cannot search it by user ID), then user ID flooding is of 363 less consequence. 365 2.3. Fingerprint Flooding 367 A malicious actor who wants to render a certificate unavailable for 368 update may generate an arbitrary number of OpenPGP certificates with 369 the targeted primary key attached as a subkey. If they can convince 370 a keystore to accept all of those certificates, and the keystore 371 returns them by subkey match during certificate update, then the 372 certificate update client will need to spend an arbitrary amount of 373 bandwidth and processing power filtering out the irrelevant data, and 374 may potentially give up before discovering the certificate of 375 interest. 377 A malicious actor may also want to confuse a certificate discovery 378 request that was targeted at a particular subkey, by binding that 379 subkey to multiple bogus certificates. If these bogus certificates 380 are ingested and redistributed by the keystore, then a certificate 381 discovery client may receive a set of certificates that cannot be 382 adequately distinguished. 384 2.4. Keystore Flooding 386 A public keystore that accepts arbitrary OpenPGP material and is 387 append-only is at risk of being overwhelmed by sheer quantity of 388 malicious uploaded packets. This is a risk even if the user ID space 389 is not being deliberately flooded, and if individual certificates are 390 protected from flooding by any of the mechanisms described later in 391 this document. 393 The keystore itself can become difficult to operate if the total 394 quantity of data is too large, and if it is a synchronizing 395 keyserver, then the quantities of data may impose unsustainable 396 bandwidth costs on the operator as well. 398 Effectively mitigating against keystore flooding requires either 399 abandoning the append-only property that some keystores prefer, or 400 imposing very strict controls on initial ingestion. 402 2.5. Toxic Data 404 Like any large public dataset, it's possible that a keystore ends up 405 hosting some content that is legally actionable in some 406 jurisdictions, including libel, child pornography, material under 407 copyright or other "intellectual property" controls, blasphemy, hate 408 speech, etc. 410 A public keystore that accepts and redistributes arbitrary content 411 may face risk due to uploads of toxic data. 413 3. Keystore Interfaces 415 Some keystores have simple interfaces, like files present in a local 416 filesystem. But many keystores offer an API for certificate 417 retrieval of different types. This section documents a set of useful 418 interactions that a client may have with such a keystore. 420 They are represented in abstract form, and are not intended to be the 421 full set of interfaces offered by any keystore, but rather a 422 convenient way to think about the operations that make the keystore 423 useful for its clients. 425 Not all keystores may offer all of these interfaces, or they may 426 offer them in subtly different forms, but clients will nevertheless 427 try to perform something like these operations with keystores that 428 they interact with. 430 3.1. Certificate Update 432 This is the simplest keystore operation. The client sends the 433 keystore the full fingerprint of the certificate's primary key, and 434 the keystore sends the client the corresponding certificate (or 435 nothing, if the keystore does not contain a certificate with a 436 matching primary key). 438 keystore.cert_update(primary_fpr) -> certificate? 440 A client uses certificate update to retrieve the full details of a 441 certificate that it already knows about. For example, it might be 442 interested in updates to the certificate known to the keystore, 443 including revocations, expiration updates, new third-party 444 certifications, etc. 446 Upon successful update, the client SHOULD merge the retrieved 447 certificate with its local copy. 449 Not all keystores offer this operation. For example, clients cannot 450 use WKD ([I-D.koch-openpgp-webkey-service]) or OPENPGPKEY ([RFC7929] 451 for certificate update. 453 3.2. Certificate Discovery 455 If a client is aware of an OpenPGP signature or certification that it 456 cannot verify because it does not know the issuing certificate, it 457 may consult a keystore to try to discover the certificate based on 458 the Issuer or Issuer Fingerprint subpacket in the signature or 459 certification it is trying to validate. 461 keystore.cert_discovery(keyid|fpr) -> certificate_list 463 This is subtly different from certificate update (Section 3.1) in 464 three ways: 466 o it may return more than one certificate (e.g., when multiple 467 certificates share a subkey, or when a primary key on one 468 certificate is a subkey on another) 470 o it is willing to accept searches by short key ID, not just 471 fingerprint 473 o it is willing to match against a subkey, not just a primary key 475 While a certificate discovery client does not initially know the 476 certificate it is looking for, it's possible that the returned 477 certificate is one that the client already knows about. For example, 478 a new subkey may have been added to a certificate. 480 Upon successful discovery, the client SHOULD merge any retrieved 481 certificates with discovered local copies (as determined by primary 482 key), and then evaluate the original signature against any retrieved 483 certificate that appears to be valid and reasonable for use in the 484 signing context. 486 It is unclear what a client should do if multiple certificates do 487 appear to be valid for a given signature, because of ambiguity this 488 represents about the identity of the signer. However, this ambiguity 489 is similar to the ambiguity of a certificate with multiple valid user 490 IDs, which the client already needs to deal with. 492 Not all keystores offer this operation. For example, clients cannot 493 use WKD ([I-D.koch-openpgp-webkey-service]) or OPENPGPKEY ([RFC7929] 494 for certificate discovery. 496 3.3. Certificate Lookup 498 If a client wants to encrypt a message to a particular e-mail 499 address, or wants to encrypt a backup to some identity that it knows 500 of but does not have a certificate for, it may consult a keystore to 501 discover certificates that claim that identity in their user ID 502 packets. Both [I-D.koch-openpgp-webkey-service] and 503 [I-D.shaw-openpgp-hkp] offer certificate lookup mechanisms. 505 [RFC4880] User IDs are constrained only in that they are a UTF-8 506 string, but some conventions govern their practical use. See 507 Section 14.2 for more discussion of some common conventions around 508 user ID structure. 510 Note that lookup does not necessarily imply user ID or certificate 511 validation. It is entirely possible for a keystore to return a 512 certificate during lookup that the client cannot validate. 514 Abuse-resistant keystores that offer a lookup interface SHOULD 515 distinguish interfaces that perform full-string-match lookup from 516 interfaces that perform e-mail address based lookup. 518 3.3.1. Full User ID Lookup 520 The most straightforward form of certificate lookup asks for the set 521 of all certificates that contain a user ID that exactly and 522 completely matches the query parameter supplied by the client. 524 keystore.cert_lookup(uid) -> certificate_list 525 In its simplest form, this match is done by a simple bytestring 526 comparison. More sophisticated keystores MAY perform the comparison 527 after applying [UNICODE-NORMALIZATION] form NFC to both the "uid" 528 query and the user IDs from the stored certificates. 530 3.3.2. E-mail Address Lookup 532 However, some common use cases look for specific patterns in the user 533 ID rather than the entire user ID. Most useful to many existing 534 OpenPGP clients is a lookup by e-mail address. 536 keystore.cert_lookup(addr) -> certificate_list 538 For certificates with a user ID that matches the structure of an 539 [RFC5322] "name-addr" or "addr-spec", a keystore SHOULD extract the 540 "addr-spec" from the user ID, canonicalize it (see Section 14.3), and 541 compare it to the canonicalized form of of the "addr" query 542 parameter. 544 3.3.3. Other Lookup Mechanisms 546 Some keystores offer other forms of substring or regular expression 547 matching against the stored user IDs. These other forms of lookup 548 may be useful in some contexts (e.g., Section 13.7), but they may 549 also represent privacy concerns (e.g., Section 16.1), and they may 550 impose additional computational or indexing burdens on the keystore. 552 3.4. Certificate Validation 554 An OpenPGP client may assess certificate and user ID validity based 555 on many factors, some of which are directly contained in the 556 certificate itself (e.g., third-party certifications), and some of 557 which are based on the context known to the client, including: 559 o Whether it has seen e-mails from that address signed by that 560 certificate in the past, 562 o How long it has known about the certificate, 564 o Whether the certificate was fetched from a keystore that asserts 565 validity of the user ID or some part of it (such as the e-mail 566 address). 568 A keystore MAY facilitate clients pursuing this last point of 569 contextual corroboration via a direct interface: 571 keystore.cert_validate(primary_fpr, uid) -> boolean 572 In an e-mail-specific context, the client might only care about the 573 keystore's opinion about the validity of the certificate for the 574 e-mail address portion of the user ID only: 576 keystore.cert_validate(primary_fpr, addr) -> boolean 578 For some keystores, the presence of a certificate in the keystore 579 alone implies that the keystore asserts the validity of all user IDs 580 in the certificate retrieved. For others, the presence in the 581 keystore applies only to some part of the user ID. For example, 582 [PGP-GLOBAL-DIRECTORY] will only return user IDs that have completed 583 an e-mail validation step, so presence in that keystore implies an 584 assertion of validity of the e-mail address part of the user IDs 585 returned, but makes no claim about the "display-name" portion of any 586 returned user IDs. Note that a client retrieving a certificate from 587 such a keystore may merge the certificate with a local copy - but the 588 validity asserted by the keystore of course has no bearing on the 589 packets that the keystore did not return. 591 In a more subtle example, the retrieval of a certificate looked up 592 via WKD ([I-D.koch-openpgp-webkey-service]) or DANE ([RFC7929]) 593 should only be interpreted as a claim of validity about any user ID 594 which matches the e-mail address by which the certificate was looked 595 up, with no claims made about any "display-name" portions, or about 596 any user ID that doesn't match the queried e-mail address at all. 598 A keystore that offers some sort of validation interface may also 599 change its opinion about the validity of a given certificate or user 600 ID over time; the interface described above only allows the client to 601 ask about the keystore's current opinion, but a more complex 602 interface might be capable of describing the keystore's assertion 603 over time. See also Section 13.5. 605 An abuse-resistant keystore that clients rely on for any part of 606 their certificate validation process SHOULD offer a distinct 607 interface for making assertions about certificate and user ID 608 validity to help clients avoid some of the subtleties involved with 609 inference based on presence described above. 611 Note that the certificate validation operation as described above has 612 a boolean response. While a "true" response indicates that keystore 613 believes the user ID or e-mail address is acceptable for use with the 614 certificate referred to by the public key fingerprint, a "false" 615 response doesn't necessarily mean that the keystore actively thinks 616 that the certificate is actively bad, or must not be used for the 617 referenced identity. Rather, "false" is the default state: no 618 opinion is expressed by the keystore, and the client is left to make 619 their own inference about validity based on other factors. A 620 keystore MAY offer a more nuanced validity interface; if it does, it 621 SHOULD explicitly document the semantics of the different response 622 types so that clients can make appropriate judgement. 624 3.5. Certificate Submission 626 Different keystores have different ways to submit a certificate for 627 consideration for ingestion, including: 629 o a simple upload of a certificate via http 631 o round-trip e-mail verification 633 o proof of presence in some other service 635 o vouching, or other forms of multi-party attestation 637 Because these schemes vary so widely, this document does not attempt 638 to describe the keystore certificate submission process in detail. 639 However, guidance can be found for implementations that generate, 640 manage, and submit certificates in Section 12. 642 4. Simple Mitigations 644 These steps can be taken by any keystore that wants to avoid 645 obviously malicious abuse. They can be implemented on receipt of any 646 new packet, and are based strictly on the structure of the packet 647 itself. 649 4.1. Decline Large Packets 651 While [RFC4880] permits OpenPGP packet sizes of arbitrary length, 652 OpenPGP certificates rarely need to be so large. An abuse-resistant 653 keystore SHOULD reject any OpenPGP packet larger than 8383 octets. 654 (This cutoff is chosen because it guarantees that the packet size can 655 be represented as a one- or two-octet [RFC4880] "New Format Packet 656 Length", but it could be reduced further) 658 This may cause problems for user attribute packets that contain large 659 images, but it's not clear that these images are concretely useful in 660 any context. Some keystores MAY extend this limit for user attribute 661 packets specifically, but SHOULD NOT allow even user attributes 662 packets larger than 65536 octets. 664 4.2. Enforce Strict User IDs 666 [RFC4880] indicates that User IDs are expected to be UTF-8 strings. 667 An abuse-resistant keystore MUST reject any user ID that is not valid 668 UTF-8. 670 Some abuse-resistant keystores MAY only accept User IDs that meet 671 even stricter conventions, such as an [RFC5322] "name-addr" or "addr- 672 spec", or a URL like "ssh://host.example.org" (see Section 14.2). 674 As simple text strings, User IDs don't need to be nearly as long as 675 any other packets. An abuse-resistant keystore SHOULD reject any 676 user ID packet larger than 1024 octets. 678 4.3. Scoped User IDs 680 Some abuse-resistant keystores may restrict themselves to publishing 681 only certificates with User IDs that match a specific pattern. For 682 example, [RFC7929] encourages publication in the DNS of only 683 certificates whose user IDs refer to e-mail addresses within the DNS 684 zone. [I-D.koch-openpgp-webkey-service] similarly aims to restrict 685 publication to certificates relevant to the specific e-mail domain. 687 4.4. Strip or Standardize Unhashed Subpackets 689 [RFC4880] signature packets contain an "unhashed" block of 690 subpackets. These subpackets are not covered by any cryptographic 691 signature, so they are ripe for abuse. 693 An abuse-resistant keystore SHOULD strip out all unhashed subpackets 694 but the following exceptions: 696 4.4.1. Issuer Fingerprint 698 Some certifications only identify the issuer of the certification by 699 an unhashed Issuer or Issuer Fingerprint subpacket. If a 700 certification's hashed subpacket section has no Issuer Fingerprint 701 (see [I-D.ietf-openpgp-rfc4880bis]) subpacket, then an abuse- 702 resistant keystore that has cryptographically validated the 703 certification SHOULD synthesize an appropriate Issuer Fingerprint 704 subpacket and include it in the certification's unhashed subpackets. 706 4.4.2. Cross-sigs 708 Some Primary Key Binding Signatures ("cross-sigs") are distributed as 709 unhashed subpackets in a Subkey Binding Signature. A 710 cryptographically-validating abuse-resistant keystore SHOULD be 711 willing to redistribute a valid cross-sig as an unhashed subpacket. 713 The redistributed unhashed cross-sig itself should be stripped of all 714 unhashed subpackets. 716 4.4.3. First-party Attestations 718 Some third-party certifications are attested to by the certificate 719 primary key itself in an unhashed subpacket, as described in 720 Section 10. A cryptographically-validating abuse-resistant keystore 721 SHOULD be willing to redistribute a valid first-party attestation as 722 an unhashed subpacket. 724 The redistributed first-party attestation itself should be stripped 725 of all unhashed subpackets. 727 4.5. Decline User Attributes 729 Due to size concerns, some abuse-resistant keystores MAY choose to 730 ignore user attribute packets entirely, as well as any certifications 731 that cover them. 733 4.6. Decline Non-exportable Certifications 735 An abuse-resistant keystore MUST NOT accept any certification that 736 has the "Exportable Certification" subpacket present and set to 0. 737 While most keystore clients will not upload these "local" 738 certifications anyway, a reasonable public keystore that wants to 739 minimize data has no business storing or distributing these 740 certifications. 742 4.7. Decline Data From the Future 744 Many OpenPGP packets have time-of-creation timestamps in them. An 745 abuse-resistant keystore with a functional real-time clock MAY decide 746 to only accept packets whose time-of-creation is in the past. 748 Note that some OpenPGP implementations may pre-generate OpenPGP 749 material intended for use only in some future window (e.g. "Here is 750 the certificate we plan to use to sign our software next year; do not 751 accept signatures from it until then."), and may use modified time- 752 of-creation timestamps to try to achieve that purpose. This material 753 would not be distributable ahead of time by an abuse-resistant 754 keystore that adopts this mitigation. 756 4.8. Accept Only Profiled Certifications 758 An aggressively abuse-resistant keystore MAY decide to only accept 759 certifications that meet a specific profile. For example, it MAY 760 reject certifications with unknown subpacket types, unknown 761 notations, or certain combinations of subpackets. This can help to 762 minimize the amount of room for garbage data uploads. 764 Any abuse-resistant keystore that adopts such a strict posture should 765 clearly document what its expected certificate profile is, and should 766 have a plan for how to extend the profile if new types of 767 certification appear that it wants to be able to distribute. 769 Note that if the profile is ever restricted (rather than extended), 770 and the restriction is applied to the material already present, such 771 a keystore is no longer append-only (please see Section 7). 773 4.9. Accept Only Certificates Issued by Designated Authorities 775 An abuse-resistant keystore capable of cryptographic validation MAY 776 retain a list of designated authorities, typically in the form of a 777 set of known public keys. Upon receipt of a new OpenPGP certificate, 778 the keystore can decide whether to accept or decline each user ID of 779 the certificate based whether that user ID has a certification that 780 was issued by one or more of the designated authorities. 782 If no user IDs are certified by designated authority, such a keystore 783 SHOULD decline the certificate and its primary key entirely. Such a 784 keystore SHOULD decline to retain or propagate all certifications 785 associated with each accepted user ID except for first-party 786 certifications and certifications by the designated authorities. 788 The operator of such a keystore SHOULD have a clear policy about its 789 set of designated authorities. 791 Given the ambiguities about expiration and revocation, such a 792 keyserver SHOULD ignore expiration and revocation of authority 793 certifications, and simply accept and retain as long as the 794 cryptographic signature is valid. 796 Note that if any key is removed from the set of designated 797 authorities, and that change is applied to the existing keystore, 798 such a keystore may no longer be append-only (please see Section 7). 800 4.10. Decline Packets by Blocklist 802 The maintainer of the keystore may keep a specific list of "known- 803 bad" material, and decline to accept or redistribute items matching 804 that blocklist. The material so identified could be anything, but 805 most usefully, specific public keys or User IDs could be blocked. 807 Note that if a blocklist grows to include an element already present 808 in the keystore, it will no longer be append-only (please see 809 Section 7). 811 Some keystores may choose to apply a blocklist only at retrieval time 812 and not apply it at ingestion time. This allows the keystore to be 813 append-only, and permits synchronization between keystores that don't 814 share a blocklist, and somewhat reduces the attacker's incentive for 815 flooding the keystore (see Section 5 for more discussion). 817 Note that development and maintenance of a blocklist is not without 818 its own potentials for abuse. For one thing, the blocklist may 819 itself grow without bound. Additionally, a blocklist may be socially 820 or politically contentious as it may describe data that is toxic 821 (Section 2.5) in one community or jurisdiction but not another. 822 There needs to be a clear policy about how it is managed, whether by 823 delegation to specific decision-makers, or explicit tests. 824 Furthermore, the existence of even a well-intentioned blocklist may 825 be an "attractive nuisance," drawing the interest of would-be censors 826 or other attacker interested in controlling the ecosystem reliant on 827 the keystore in question. 829 5. Retrieval-time Mitigations 831 Most of the abuse mitigations described in this document are 832 described as being applied at certificate ingestion time. It's also 833 possible to apply the same mitigations when a certificate is 834 retrieved from the keystore (that is, during certificate lookup, 835 update, or discovery). Applying an abuse mitigation at retrieval 836 time may help a client defend against a user ID flooding 837 (Section 2.2), certificate flooding (Section 2.1), or fingerprint 838 flooding (Section 2.3) attack. It may also help a keystore limit its 839 liability for redistributing toxic data (Section 2.5). However, only 840 mitigations applied at ingestion time are able to mitigate keystore 841 flooding attacks (Section 2.4). 843 Some mitigations (like the non-append-only mitigations described in 844 Section 7) may be applied as filters at retrieval time, while still 845 allowing access to the (potentially much larger) unfiltered dataset 846 associated given certificate or user ID via a distinct interface. 848 The rest of this section documents specific mitigations that are only 849 relevant at retrieval time (certificate discovery, lookup, or 850 update). 852 5.1. Redacting User IDs 854 Some abuse-resistant keystores may accept and store user IDs but 855 decline to redistribute some or all of them, while still distributing 856 the certifications that cover those redacted user IDs. This draft 857 refers to such a keystore as a "user ID redacting" keystore. 859 The certificates distributed by such a keystore are technically 860 invalid [RFC4880] "transferable public keys", because they lack a 861 user ID packet, and the distributed certifications cannot be 862 cryptographically validated independently. However, an OpenPGP 863 implementation that already knows the user IDs associated with a 864 given primary key will be capable of associating each certification 865 with the correct user ID by trial signature verification. 867 5.1.1. Certificate Update with Redacted User IDs 869 A user ID redacting keystore is useful for certificate update by a 870 client that already knows the user ID it expects to see associated 871 with the certificate. For example, a client that knows a given 872 certificate currently has two specific user IDs could access the 873 keystore to learn that one of the user IDs has been revoked, without 874 any other client learning the user IDs directly from the keystore. 876 5.1.2. Certificate Discovery with Redacted User IDs 878 A user ID redacting keystore is somewhat less useful for clients 879 doing certificate discovery. Consider the circumstance of receiving 880 a signed e-mail without access to the signing certificate. If the 881 verifier retrieves the certificate from a user ID redacting keystore 882 by via the Issuer Fingerprint from the signature, and the signature 883 validates, the received certificate might not be a valid 884 "transferable public key" unless the client can synthesize the proper 885 user ID. 887 A reasonable client that wants to validate a certification in the 888 user ID redacted certificate SHOULD try to synthesize possible user 889 IDs based on the value of the [RFC5322] From: header in the message: 891 o Decode any [RFC2047] encodings present in the raw header value, 892 converting into UTF-8 [UNICODE-NORMALIZATION] form C (NFC), 893 trimming all whitespace from the beginning and the end of the 894 string. 896 o The resulting string should be an [RFC5322] "name-addr" or "addr- 897 spec". 899 o If it is a "name-addr", convert the UTF-8 string into an OpenPGP 900 user ID and check whether the certification validates, terminating 901 on success. 903 * If the test fails, extract the "addr-spec" from the "name-addr" 904 and continue. 906 o Canonicalize the "addr-spec" according to Section 14.3, and check 907 whether the certification validates, terminating on success. 909 o If it doesn't validate wrap the canonicalized "addr-spec" in 910 angle-brackets ("<" and ">") and test the resulting minimalist 911 "name-addr" against the certification, terminating on success. 913 o If all of the above fails, synthesis has failed. 915 5.1.3. Certificate Lookup with Redacted User IDs 917 It's possible (though non-intuitive) to use a user ID redacting 918 keystore for certificate lookup. Since the keystore retains (but 919 does not distribute) the user IDs, they can be used to select 920 certificates in response to a search. The OpenPGP certificates sent 921 back in response to the search will not contain the user IDs, but a 922 client that knows the full user ID they are searching for will be 923 able to verify the returned certifications. 925 Certificate lookup from a user ID redacting keystore works better for 926 certificate lookup by exact user ID match than it does for substring 927 match, because a client that retrieves a certificate via a substring 928 match may not be able to reconstruct the redacted user ID. 930 However, without some additional restrictions on which certifications 931 are redistributed (whether the user ID is redacted or not), 932 certificate lookup can be flooded (see Section 15.1). 934 5.1.4. Hinting Redacted User IDs 936 To ensure that the distributed certificate is at least structurally a 937 valid [RFC4880] transferable public key, a user ID redacting keystore 938 MAY distribute an empty user ID (an OpenPGP packet of tag 13 whose 939 contents are a zero-octet string) in place of the omitted user ID. 940 This two-octet replacement user ID packet ("\xb4\x00") is called the 941 "unstated user ID". 943 To facilitate clients that match certifications with specific user 944 IDs, a user ID redacting keystore MAY insert a non-hashed notation 945 subpacket into the certification. The notation will have a name of 946 "uidhash", with 0x80 ("human-readable") flag unset. The value of 947 such a notation MUST be 32 octets long, and contains the SHA-256 948 cryptographic digest of the UTF-8 string of the redacted user ID. 950 A certificate update client which receives such a certification after 951 the "unstated user ID" SHOULD compute the SHA-256 digest of all user 952 IDs it knows about on the certificate, and compare the result with 953 the contents of the "uidhash" notation to decide which user ID to try 954 to validate the certification against. 956 5.1.5. User ID Recovery by Client Brute Force 958 User ID redaction is at best an imperfect process. Even if a 959 keystore redacts a User ID, if it ships a certification over that 960 user ID, an interested client can guess user IDs until it finds one 961 that causes the signature to verify. This is even easier when the 962 space of legitimate user IDs is relatively small, such as the set of 963 commonly-used hostnames 965 5.2. Primary-key Only Certificate Update 967 Abuse-resistant keystores can defend against a fingerprint flooding 968 Section 2.3 attack during certificate update by implementing a 969 narrowly-constrained certificate update interface. 971 Such a keystore MUST accept only a full fingerprint as the search 972 parameter from the certificate update client, and it MUST return at 973 most a single certificate whose primary key matches the requested 974 fingerprint. It MUST NOT return more than one certificate, and it 975 MUST NOT return any certificate whose primary key does not match the 976 fingerprint. In particular, it MUST NOT return certificates where 977 only the subkey fingerprint matches. 979 Note that [I-D.shaw-openpgp-hkp] does not offer the primitive 980 described in Section 3.1 exactly. In that specification, the set of 981 keys returned by a "get" operation with a "search" parameter that 982 appears to be a full fingerprint is ambiguous. Some popular 983 implementations (e.g., [SKS]) do not currently implement this 984 mitigation, because they return certificates with subkeys that match 985 the fingerprint. 987 5.3. Require Valid Cross-Sigs for Certificate Discovery 989 By definition, certificate discovery needs to be able to match 990 subkeys, not just primary keys. This means that the mitigation in 991 Section 5.2 is ineffective for a keystore that offers a certificate 992 discovery interface. 994 An abuse-resistant keystore that aims to defend its certificate 995 discovery interface from a fingerprint flooding (Section 2.3) attack 996 can follow the following procedure. 998 Such a keystore MUST accept only a full fingerprint or a 64-bit key 999 ID as the search parameter from the certificate discovery client. It 1000 MUST only match that fingerprint against the following: 1002 o the fingerprint or key ID of a primary key associated with a valid 1003 certificate 1005 o the fingerprint or key ID of a cryptographically-valid subkey that 1006 also has a cross-sig. 1008 This defends against the fingerprint flooding attack because a 1009 certificate will only be returned by subkey if the subkey has agreed 1010 to be associated with the primary key (and vice versa). 1012 Note that this mitigation means that certificate discovery will fail 1013 if used for subkeys that lack cross-sigs. In particular, this means 1014 that a client that tries to use the certificate discovery interface 1015 to retrieve a certificate based on its encryption-capable subkey 1016 (e.g., taking the key ID from a Public Key Encrypted Session Key 1017 (PKESK) packet) will have no success. 1019 This is an acceptable loss, since the key ID in a PKESK is typically 1020 unverifiable anyway. 1022 6. Contextual Mitigations 1024 Some mitigations make the acceptance or rejection of packets 1025 contingent on data that is already in the keystore or the keystore's 1026 developing knowledge about the world. This means that, depending on 1027 the order that the keystore encounters the various material, or how 1028 it accesses or finds the material, the final set of material retained 1029 and distributed by the keystore might be different. 1031 While this isn't necessarily bad, it may be a surprising property for 1032 some users of keystores. 1034 6.1. Accept Only Cryptographically-verifiable Certifications 1036 An abuse-resistant keystore that is capable of doing cryptographic 1037 validation MAY decide to reject certifications that it cannot 1038 cryptographically validate. 1040 This may mean that the keystore rejects some packets while it is 1041 unaware of the public key of the issuer of the packet. 1043 6.2. Accept Only Certificates Issued by Known Certificates 1045 This is an extension of Section 4.9, but where the set of authorities 1046 is just the set of certificates already known to the keystore. An 1047 abuse-resistant keystore that adopts this strategy is effectively 1048 only crawling the reachable graph of OpenPGP certificates from some 1049 starting core. 1051 A keystore adopting the mitigation SHOULD have a clear documentation 1052 of the core of initial certificates it starts with, as this is 1053 effectively a policy decision. 1055 This mitigation measure may fail due to a compromise of any secret 1056 key that is associated with a primary key of a certificate already 1057 present in the keystore. Such a compromise permits an attacker to 1058 flood the rest of the network. In the event that such a compromised 1059 key is identified, it might be placed on a blocklist (see 1060 Section 4.10). In particular, if a public key is added to a 1061 blocklist for a keystore implementing this mitigation, and it is 1062 removed from the keystore, then all certificates that were only 1063 "reachable" from the blocklisted certificate should also be 1064 simultaneously removed. 1066 6.3. Rate-limit Submissions by IP Address 1068 Some OpenPGP keystores accept material from the general public over 1069 the Internet. If an abuse-resistant keystore observes a flood of 1070 material submitted to the keystore from a given Internet address, it 1071 MAY choose to throttle submissions from that address. When receiving 1072 submissions over IPv6, such a keystore MAY choose to throttle entire 1073 nearby subnets, as a malicious IPv6 host is more likely to have 1074 multiple addresses. 1076 This requires that the keystore maintain state about recent 1077 submissions over time and address. It may also be problematic for 1078 users who appear to share an IP address from the vantage of the 1079 keystore, including those behind a NAT, using a VPN, or accessing the 1080 keystore via Tor. 1082 6.4. Accept Certificates Based on Exterior Process 1084 Some public keystores resist abuse by explicitly filtering OpenPGP 1085 material based on a set of external processes. For example, 1086 [DEBIAN-KEYRING] adjudicates the contents of the "Debian keyring" 1087 keystore based on organizational procedure and manual inspection. 1089 6.5. Accept Certificates by E-mail Validation 1091 Some keystores resist abuse by declining any certificate until the 1092 user IDs have been verified by e-mail. When these "e-mail 1093 validating" keystores review a new certificate that has a user ID 1094 with an e-mail address in it, they send an e-mail to the associated 1095 address with a confirmation mechanism (e.g., a high-entropy HTTPS URL 1096 link) in it. In some cases, the e-mail itself is encrypted to an 1097 encryption-capable key found in the proposed certificate. If the 1098 keyholder triggers the confirmation mechanism, then the keystore 1099 accepts the certificate. 1101 Some e-mail validating keystores MAY choose to distribute 1102 certifications over all user IDs for any given certificate, but will 1103 redact (see Section 5.1) those user IDs that have not been e-mail 1104 validated. 1106 [PGP-GLOBAL-DIRECTORY] describes some concerns held by a keystore 1107 operator using this approach. [MAILVELOPE-KEYSERVER] is another 1108 example. 1110 7. Non-append-only mitigations 1112 The following mitigations may cause some previously-retained packets 1113 to be dropped after the keystore receives new information, or as time 1114 passes. This is entirely reasonable for some keystores, but it may 1115 be surprising for any keystore that expects to be append-only (for 1116 example, some keyserver synchronization techniques may expect this 1117 property to hold). 1119 Furthermore, keystores that drop old data (e.g., superseded 1120 certifications) may make it difficult or impossible for their users 1121 to reason about the validity of signatures that were made in the 1122 past. See Section 13.5 for more considerations. 1124 Note also that many of these mitigations depend on cryptographic 1125 validation, so they're typically contextual as well. 1127 A keystore that needs to be append-only, or which cannot perform 1128 cryptographic validation MAY omit these mitigations. Alternately, a 1129 keystore may omit these mitigations at certificate ingestion time, 1130 but apply these mitigations at retrieval time (during certificate 1131 update, discovery, or lookup), and offer a more verbose (non- 1132 mitigated) interface for auditors, as described in Section 5. 1134 Note that [GnuPG] anticipates some of these suggestions with its 1135 "clean" subcommand, which is documented as: 1137 Compact (by removing all signatures except the selfsig) 1138 any user ID that is no longer usable (e.g. revoked, or 1139 expired). Then, remove any signatures that are not usable 1140 by the trust calculations. Specifically, this removes 1141 any signature that does not validate, any signature that 1142 is superseded by a later signature, revoked signatures, 1143 and signatures issued by keys that are not present on the 1144 keyring. 1146 7.1. Drop Superseded Signatures 1148 An abuse-resistant keystore SHOULD drop all signature packets that 1149 are explicitly superseded. For example, there's no reason to retain 1150 or distribute a self-sig by key K over User ID U from 2017 if the 1151 keystore have a cryptographically-valid self-sig over from 1152 2019. 1154 Note that this covers both certifications and signatures over 1155 subkeys, as both of these kinds of signature packets may be 1156 superseded. 1158 Getting this right requires a nuanced understanding of subtleties in 1159 [RFC4880] related to timing and revocation. 1161 7.2. Drop Expired Signatures 1163 If a signature packet is known to only be valid in the past, there is 1164 no reason to distribute it further. An abuse-resistant keystore with 1165 access to a functional real-time clock SHOULD drop all certifications 1166 and subkey signature packets with an expiration date in the past. 1168 Note that this assumes that the keystore and its clients all have 1169 roughly-synchronized clocks. If that is not the case, then there 1170 will be many other problems! 1172 7.3. Drop Dangling User IDs, User Attributes, and Subkeys 1174 If enough signature packets are dropped, it's possible that some of 1175 the things that those signature packets cover are no longer valid. 1177 An abuse-resistant keystore which has dropped all certifications that 1178 cover a User ID SHOULD also drop the User ID packet. 1180 Note that a User ID that becomes invalid due to revocation MUST NOT 1181 be dropped, because the User ID's revocation signature itself remains 1182 valid, and needs to be distributed. 1184 A primary key with no User IDs and no subkeys and no revocations MAY 1185 itself also be removed from distribution, though note that the 1186 removal of a primary key may make it impossible to cryptographically 1187 validate other certifications held by the keystore. 1189 7.4. Drop All Other Elements of a Directly-Revoked Certificate 1191 If the primary key of a certificate is revoked via a direct key 1192 signature, an abuse-resistant keystore SHOULD drop all the rest of 1193 the associated data (user IDs, user attributes, and subkeys, and all 1194 attendant certifications and subkey signatures). This defends 1195 against an adversary who compromises a primary key and tries to flood 1196 the certificate to hide the revocation. 1198 Note that the direct key revocation signature MUST NOT be dropped. 1200 In the event that an abuse-resistant keystore is flooded with direct 1201 key revocation signatures, it should retain the hardest, earliest 1202 revocation (see also Section 14.1). 1204 In particular, if any of the direct key revocation signatures is a 1205 "hard" revocation, the abuse-resistant keystore SHOULD retain the 1206 earliest such revocation signature (by signature creation date). 1208 Otherwise, the abuse-resistant keystore SHOULD retain the earliest 1209 "soft" direct key revocation signature it has seen. 1211 If either of the above date comparisons results in a tie between two 1212 revocation signatures of the same "hardness", an abuse-resistant 1213 keystore SHOULD retain the signature that sorts earliest based on a 1214 binary string comparison of the direct key revocation signature 1215 packet itself. 1217 7.5. Implicit Expiration Date 1219 In combination with some of the dropping mitigations above, a 1220 particularly aggressive abuse-resistant keystore MAY choose an 1221 implicit expiration date for all signature packets. For example, a 1222 signature packet that claims no expiration could be treated by the 1223 keystore as expiring 3 years after issuance. This would permit the 1224 keystore to eject old packets on a rolling basis. 1226 An abuse-resistant keystore that adopts this mitigation needs a 1227 policy for handling signature packets marked with an explicit 1228 expiration that is longer than implicit maximum. The two obvious 1229 strategies are: 1231 o cap the packet's expiration to the system's implicit expiration 1232 date, or 1234 o accept the explicit expiration date. 1236 Warning: Any implementation of this idea is pretty radical, and it's 1237 not clear what it would do to an ecosystem that depends on such a 1238 keystore. It probably needs more thinking. 1240 8. Updates-only Keystores 1242 In addition to the mitigations above, some keystores may resist abuse 1243 by declining to accept any user IDs or certifications whatsoever. 1245 Such a keystore MUST be capable of cryptographic validation. It 1246 accepts primary key packets, cryptographically-valid direct-key 1247 signatures from a primary key over itself, subkeys and their 1248 cryptographically-validated binding signatures (and cross-sigs, where 1249 necessary). 1251 A client of an updates-only keystore cannot possibly use the keystore 1252 for certificate lookup, because there are no user IDs to match. And 1253 it is not particularly useful for certificate discovery, because the 1254 returned certificate would have no identity information. However, 1255 such a keystore can be used for certificate update, as it's possible 1256 to ship revocations (which are direct key signatures), new subkeys, 1257 updates to subkey expiration, subkey revocation, and direct key 1258 signature-based certificate expiration updates. 1260 Note that many popular OpenPGP implementations do not implement 1261 direct primary key expiration mechanisms, relying instead on user ID 1262 expirations. These user ID expiration dates or other metadata 1263 associated with a self-certification will not be distributed by an 1264 updates-only keystore. 1266 Certificates shipped by an updates-only keystore are technically 1267 invalid [RFC4880] "transferable public keys," because they lack a 1268 user ID packet. However many OpenPGP implementations will accept 1269 such a certificate if they already know of a user ID for the 1270 certificate, because the composite certificate resulting from a merge 1271 will be a standards-compliant transferable public key. 1273 9. First-party-only Keystores 1275 Slightly more permissive than the updates-only keystore described in 1276 Section 8 is a keystore that also permits user IDs and their self- 1277 sigs. 1279 A first-party-only keystore only accepts and distributes 1280 cryptographically-valid first-party certifications. Given a primary 1281 key that the keystore understands, it will only attach user IDs that 1282 have a valid self-sig, and will only accept and re-distribute subkeys 1283 that are also cryptographically valid (including requiring cross-sigs 1284 for signing-capable subkeys as recommended in [RFC4880]). 1286 This effectively avoids certificate flooding attacks, because the 1287 only party who can make a certificate overly large is the holder of 1288 the secret corresponding to the primary key itself. 1290 Note that a first-party-only keystore is still problematic for those 1291 people who rely on the keystore for retrieval of third-party 1292 certifications. Section 10 attempts to address this lack. 1294 9.1. First-party-only Without User IDs 1296 It is possible to operate an first-party-only keystore that 1297 redistributes certifications while declining to redistribute user IDs 1298 (see Section 5.1). This defends against concerns about publishing 1299 identifiable information, while enabling full certificate update for 1300 those keystore clients that already know the associated user IDs for 1301 a given certificate. 1303 10. First-party-attested Third-party Certifications 1305 We can augment a first-party-only keystore to allow it to distribute 1306 third-party certifications as long as the first-party has signed off 1307 on the specific third-party certification. 1309 An abuse-resistant keystore SHOULD only accept a third-party 1310 certification if it meets the following criteria: 1312 o The third-party certification MUST be cryptographically valid. 1313 Note that this means that the keystore needs to know the primary 1314 key for the issuer of the third-party certification. 1316 o The third-party certification MUST have an unhashed subpacket of 1317 type Embedded Signature, the contents of which we'll call the 1318 "attestation". This attestation is from the certificate's primary 1319 key over the third-party certification itself, as detailed in the 1320 steps below: 1322 * The attestation MUST be an OpenPGP signature packet of type 1323 0x50 (Third-Party Confirmation signature) 1325 * The attestation MUST contain a hashed "Issuer Fingerprint" 1326 subpacket with the fingerprint of the primary key of the 1327 certificate in question. 1329 * The attestation MUST NOT be marked as non-exportable. 1331 * The attestation MUST contain a hashed Notation subpacket with 1332 the name "ksok", and an empty (0-octet) value. 1334 * The attestation MUST contain a hashed "Signature Target" 1335 subpacket with "public-key algorithm" that matches the public- 1336 key algorithm of the third-party certification. 1338 * The attestation's hashed "Signature Target" subpacket MUST use 1339 a reasonably strong hash algorithm (as of this writing, any 1340 [RFC4880] hash algorithm except MD5, SHA1, or RIPEMD160), and 1341 MUST have a hash value equal to the hash over the third-party 1342 certification with all unhashed subpackets removed. 1344 * The attestation MUST be cryptographically valid, verifiable by 1345 the primary key of the certificate in question. 1347 This means that a third-party certificate will only be accepted/ 1348 distributed by the keystore if: 1350 o the keystore knows about both the first- and third-parties. 1352 o the third-party has made the identity assertion 1354 o the first-party has confirmed that they're OK with the third-party 1355 certification being distributed by any keystore. 1357 The "ksok" notification is not strictly necessary for this 1358 mitigation, but it is intended to avoid potential accidental 1359 confusion with any other use of the Third-Party Confirmation 1360 signature packet type. The author does not know of any current use 1361 that might collide. 1363 10.1. Key Server Preferences "No-modify" 1365 [RFC4880] defines "Key Server Preferences" with a "No-modify" bit. 1366 That bit has never been respected by any keyserver implementation 1367 that the author is aware of. An abuse-resistant keystore following 1368 Section 10 effectively treats that bit as always set, whether it is 1369 present in the certificate or not. 1371 10.2. Client Interactions 1373 Creating such an attestation requires multiple steps by different 1374 parties, each of which is blocked by all prior steps: 1376 o The first-party creates the certificate, and transfers it to the 1377 third party. 1379 o The third-party certifies it, and transfers their certification 1380 back to the first party. 1382 o The first party attests to the third party's certification. 1384 o Finally, the first party then transfers the compound certificate 1385 to the keystore. 1387 The complexity and length of such a sequence may represent a 1388 usability obstacle to a user who needs a third-party-certified 1389 OpenPGP certificate. 1391 No current OpenPGP client can easily create the attestations 1392 described in this section. More implementation work needs to be done 1393 to make it easy (and understandable) for a user to perform this kind 1394 of attestation. 1396 11. Keystore Client Best Practices 1398 An OpenPGP client that needs to interact with an abuse-resistant 1399 keystore can take steps to minimize the extent that its interactions 1400 with a keystore can be abused by other parties via the attacks 1401 described in Section 2. This section describes steps that an abuse- 1402 resistant client can take. 1404 11.1. Use Constrained Keystores for Lookup 1406 When performing certificate lookup, an abuse-resistant client SHOULD 1407 prefer to query constrained keystores to avoid the risks described in 1408 Section 15.1. 1410 11.2. Normalize Addresses and User IDs for Lookup 1412 When performing lookup by e-mail address, an abuse-resistant client 1413 SHOULD consider canonicalizing the e-mail address before searching 1414 (see Section 14.3). 1416 When searching by full User ID, unless there is a strong reason to 1417 believe that a specific non-normalized form is preferable, an abuse- 1418 resistant client SHOULD normalize the entire user ID into 1420 [UNICODE-NORMALIZATION] Form C (NFC) before performing certificate 1421 lookup. 1423 11.3. Avoid Fuzzy Lookups 1425 Certificate lookup by arbitrary substring matching, or regular 1426 expression is prone to abuse. An abuse-resistant client SHOULD 1427 prefer exact-userid or exact-email match lookups where possible. 1429 In particular, an abuse-resistant client should avoid trying to offer 1430 reliable functionality that performs these sort of fuzzy lookups, and 1431 SHOULD warn the user about risks of abuse if the user triggers a 1432 codepath that unavoidably performs such a fuzzy lookup. 1434 11.4. Prefer Full Fingerprint for Discovery and Update 1436 Key IDs are inherently weaker and easier to spoof or collide than 1437 full fingerprints. Where possible, an abuse-resistant keystore 1438 client SHOULD use the full fingerprint when interacting with the 1439 keystore. 1441 11.5. Use Caution with Keystore-provided Validation 1443 When an abuse-resistant client relies on a keystore for certificate 1444 validation, many things can go subtly wrong if the client fails to 1445 closely track the specific semantics of the keystore's validation 1446 claims. 1448 For example, a certificate published by WKD 1449 ([I-D.koch-openpgp-webkey-service]) at 1450 "https://openpgpkey.example.org/.well-known/openpgpkey/hu/ 1451 iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=joe.doe" offers a validation claim 1452 only for the e-mail address "joe.doe@example.org". If the 1453 certificate retrieved at that address contains other user IDs, or if 1454 the user ID containing that e-mail address contains an [RFC5322] 1455 "display-name", none of that information should be considered 1456 "validated" by the fact that the certificate was retrieved via 1457 certificate lookup by WKD. 1459 When certificate validation is represented more generally by a 1460 keystore via certificate retrieval (e.g. from an e-mail validating 1461 keyserver that has no distinct certificate validation interface), the 1462 thing validated is the certificate received from the keystore, and 1463 not the result of the merge into any local copy of the certificate 1464 already possessed by the client. 1466 Consider also timing and duration of these assertions of validity, 1467 which represent a subtle tradeoff between privacy and risk as 1468 described in Section 16.4. 1470 12. Certificate Generation and Management Best Practices 1472 An OpenPGP implementation that generates or manages certificates and 1473 expects to distribute them via abuse-resistant keystores can take 1474 steps to ensure that the certificates generated are more likely to be 1475 accessible when needed. This section describes steps such an abuse- 1476 sensitive implementation can take. 1478 12.1. Canonicalized E-Mail Addresses 1480 E-mail addresses can be written in many different ways. An abuse- 1481 sensitive implementation considering attaching a user ID containing 1482 an e-mail address on a certificate SHOULD ensure that the e-mail 1483 address is structured as simply as possible. See Section 14.3 for 1484 details about e-mail address canonicalization. 1486 For example, if the e-mail domain considers the local part to be 1487 case-insensitive (as most e-mail domains do today), if a proposed 1488 user ID contains the "addr-spec": "Alice@EXAMPLE.org", the 1489 implementation SHOULD warn the user and, if possible, propose 1490 replacing the "addr-spec" part of the user ID with 1491 "alice@example.org". 1493 12.2. Normalized User IDs 1495 User IDs are arbitrary UTF-8 strings, but UTF-8 offers several ways 1496 to represent the same string. An abuse-sensitive implementation 1497 considering attaching a user ID to a certificate SHOULD normalize the 1498 string using [UNICODE-NORMALIZATION] Form C (NFC) before creating the 1499 self-sig. 1501 At the same time, the implementation MAY also warn the user if the 1502 "compatibility" normalized form (NFKC) differs from the candidate 1503 user ID and, if appropriate, offer to convert the user ID to 1504 compatibility normalized form at the user's discretion. 1506 12.3. Avoid Large User Attributes 1508 An abuse-sensitive implementation SHOULD warn the user when attaching 1509 a user attribute larger than 8383 octets, and SHOULD refuse to attach 1510 user attributes entirely larger than 65536 octets. (See Section 4.1) 1512 12.4. Provide Cross-Sigs 1514 [RFC4880] requires cross-sigs for all signing-capable subkeys, but is 1515 agnostic about the use of cross-sigs for subkeys of other 1516 capabilities. 1518 An abuse-sensitive implementation that wants a certificate to be 1519 discoverable by subkey SHOULD provide cross-sigs for any subkey 1520 capable of making a cross-sig. 1522 12.5. Provide Issuer Fingerprint Subpackets 1524 Issuer subpackets contain only 64-bit key IDs. Issuer Fingerprint 1525 subpackets contain an unambiguous designator of the issuing key, 1526 avoiding the ambiguities described in Section 13.2. Abuse-sensitive 1527 implementations SHOULD providue Issuer Fingerprint subpackets. 1529 12.6. Put Cross-Sigs and Issuer Fingerprint in Hashed Subpackets 1531 Unhashed subpackets may be stripped or mangled. Placing cross-sigs 1532 and issuer fingerprint subpackets in the hashed subpackets will 1533 ensure that they are propagated by any cryptographically-validating 1534 keystore, even if that keystore fails to observe the exceptions in 1535 Section 4.4. 1537 12.7. Submit Certificates to Restricted, Lookup-Capable Keystores 1539 If an abuse-sensitive implementation wants other peers to be able to 1540 to retrieve the managed certificate by certificate lookup (that is, 1541 by searching based on user ID or e-mail address), it needs to be 1542 aware that submission to an unrestricted keystore is not reliable 1543 (see Section 15.1 for more details). 1545 Consequently, such an implementation SHOULD submit the managed 1546 certificate to restricted, lookup-capable keystores where possible, 1547 as those keystores are more likely to be able to offer reliable 1548 lookup. 1550 13. Side Effects and Ecosystem Impacts 1552 13.1. Designated Revoker 1554 A first-party-only keystore as described in Section 9 might decline 1555 to distribute revocations made by the designated revoker. This is a 1556 risk to certificate-holder who depend on this mechanism, because an 1557 important revocation might be missed by clients depending on the 1558 keystore. 1560 FIXME: adjust this document to point out where revocations from a 1561 designated revoker SHOULD be propagated, maybe even in first-party- 1562 only keystores. 1564 13.2. Key IDs vs. Fingerprints in Certificate Discovery 1566 During signature verification, a user performing certificate 1567 discovery against a keystore SHOULD prefer to use the full 1568 fingerprint as an index, rather than the 64-bit key ID. Using a 1569 64-bit key ID is more likely to run into collision attacks; and if 1570 the retrieved certificate has a matching key ID but the signature 1571 cannot be validated with it, the client is in an ambiguous state - 1572 did it retrieve the wrong certificate, or is the signature incorrect? 1573 Using the fingerprint resolves the ambiguity: the signature is 1574 incorrect, because the a fingerprint match is overwhelmingly stronger 1575 than a key ID match. 1577 Unfortunately, many OpenPGP implementations distribute signatures 1578 with only an Issuer subpacket, so a client attempting to find such a 1579 certificate MAY perform certificate discovery based on only the key 1580 ID. 1582 A keystore that offers certificate discovery MAY choose to require 1583 full fingerprint, but such a keystore will not be useful for a client 1584 attempting to verify a bare signature from an unknown party if that 1585 signature only has an Issuer subpacket (and no Issuer Fingerprint 1586 subpacket). 1588 13.3. In-band Certificates 1590 There are contexts where it is expected and acceptable that the 1591 signature appears without its certificate: for example, if the set of 1592 valid signers is already known (as in some OpenPGP-signed operating 1593 system updates), shipping the certificate alongside the signature 1594 would be pointless bloat. 1596 However, OpenPGP signatures are often found in contexts where the 1597 certificate is not yet known by the verifier. For example, many 1598 OpenPGP-signed e-mails are not accompanied by the signing 1599 certificate. 1601 In another example, the use of authentication-capable OpenPGP keys in 1602 standard SSH connections do not contain the full OpenPGP 1603 certificates, which means that the SSH clients and servers need to 1604 resort to out-of-band processes if evaluation of the OpenPGP 1605 certificates is necessary. 1607 The certificate discovery interface offered by keystores is an 1608 attempt to accommodate these situations. But in the event that a 1609 keystore is unavailable, does not know the certificate, or suffers 1610 from a flooding attack, signature validation may fail unnecessarily. 1611 In an encrypted e-mail context specifically, such a failure may also 1612 limit the client's ability to reply with an encrypted e-mail. 1614 Certificate discovery also presents a potential privacy concern for 1615 the signature verifier, as noted in Section 16.5. 1617 These problematic situations can be mitigated by shipping the 1618 certificate in-band, alongside the signature. Signers SHOULD adopt 1619 this practice where possible to reduce the dependence of the verifier 1620 on the keystores for certificate discovery. [AUTOCRYPT] is an 1621 example of e-mail recommendations that include in-band certificates. 1623 13.3.1. In-band Certificate Minimization and Validity 1625 OpenPGP certificates are potenitally large. When distributing an in- 1626 band certificate alongside a signature in a context where size is a 1627 concern (e.g. bandwidth, latency, or storage costs are a factor), the 1628 distributor SHOULD reduce the size of the in-band certificate by 1629 stripping unnecessary packets. For example, the distributor may: 1631 o Strip certification and signature packets that (due to creation 1632 and expiration time) are not relevant to the time of the signature 1633 itself. This ensures that the reduced certificate is 1634 contemporaneously valid with the signature. 1636 o Strip irrelevant subkeys (and associated Subkey Binding Signature 1637 packets and cross-sigs). If the signature was issued by a 1638 signing-capable subkey, that subkey (and its binding signature and 1639 cross-sig) are clearly relevant. Other signing-capable subkeys 1640 are likely to be irrelevant. But determining which other subkeys 1641 are relevant may be context-specific. For example, in the e-mail 1642 context, an encryption-capable subkey is likely to be contextually 1643 relevant, because it enables the recipient to reply encrypted, and 1644 therefore should not be stripped. 1646 o Strip user IDs (and associated certifications) that are unlikely 1647 to be relevant to the signature in question. For example, in the 1648 e-mail context, strip any user IDs that do not match the declared 1649 sender of the message. 1651 o Strip third-party certifications that are unlikely to be relevant 1652 to the verifier. Doing this successfully requires some knowledge 1653 about what the third-parties the recipient is likely to care 1654 about. Stripping all third-party certifications is a simple means 1655 of certificate reduction. The verifier of such a certificate may 1656 need to do certificate update against their preferred keystore to 1657 learn about third-party certifications useful to them. 1659 13.4. Certification-capable Subkeys 1661 Much of this discussion assumes that primary keys are the only 1662 certification-capable keys in the OpenPGP ecosystem. Some proposals 1663 have been put forward that assume that subkeys can be marked as 1664 certification-capable. If subkeys are certification-capable, then 1665 much of the reasoning in this draft becomes much more complex, as 1666 subkeys themselves can be revoked by their primary key without 1667 invalidating the key material itself. That is, a subkey can be both 1668 valid (in one context) and invalid (in another context) at the same 1669 time. So questions about what data can be dropped (e.g. in 1670 Section 7) are much fuzzier, and the underlying assumptions may need 1671 to be reviewed. 1673 If some OpenPGP implementations accept certification-capable subkeys, 1674 but an abuse-resistant keystore does not accept certifications from 1675 subkeys in general, then interactions between that keystore and those 1676 implementations may be surprising. 1678 13.5. Assessing Certificates in the Past 1680 Online protocols like TLS perform signature and certificate 1681 evaluation based entirely on the present time. If a certificate that 1682 signs a TLS handshake message is invalid now, it doesn't matter 1683 whether it was valid a week ago, because the present TLS session is 1684 the context of the evaluation. 1686 But OpenPGP signatures are often evaluated at some temporal remove 1687 from when the signature was made. For example, software packages are 1688 signed at release time, but those signatures are validated at 1689 download time. A verifier that does not already know the certificate 1690 that made the signature will need to perform certificate discovery 1691 against some set of keystores to find a certificate with which to 1692 check the signature. 1694 Further complicating matters, the composable nature of an OpenPGP 1695 certificate means that the certificate associated with any particular 1696 signing key (primary key or subkey) can transform over time. So when 1697 evaluating a signature that appears to have been made by a given 1698 certificate, it may be better to try to evaluate the certificate at 1699 the time the signature was made, rather than the present time. 1701 13.5.1. Point-in-time Certificate Evaluation 1703 When evaluating a certificate at a time T in the past (for example, 1704 when trying to validate a data signature by that certificate that was 1705 created at time T), one approach is to discard all packets from the 1706 certificate if the packet has a creation time later than T. Then 1707 evaluate the resulting certificate from the remaining packets in the 1708 context of time T. 1710 However, any such evaluation MUST NOT ignore "hard" OpenPGP key 1711 revocations, regardless of their creation date. (see Section 14.1). 1713 13.5.2. Signature Verification and Non-append-only Keystores 1715 If a non-append-only keystore (Section 7) has dropped superseded 1716 (Section 7.1) or expired (Section 7.2) certifications, it's possible 1717 for the certificate composed of the remaining packets to have no 1718 valid first-party certification at the time that a given signature 1719 was made. If a user performs certificate discovery against such a 1720 keystore, the certificate it retrieves would be invalid according to 1721 [RFC4880], and consequently verification of any signature by that 1722 certificate would fail. 1724 One simple mitigation to this problem is to ship a contemporaneously- 1725 valid certificate in-band alongside the signature (see Section 13.3). 1727 If the distributor does this, then the verifier need only learn about 1728 revocations. If knowledge about revocation is needed, the verifier 1729 might perform a certificate update (not "certificate discovery") 1730 against any preferred keystore, including non-append-only keystores, 1731 merging what it learns into the in-band contemporary certificate. 1733 Then the signature verifier can follow the certificate evaluation 1734 process outlined in Section 13.5.1, using the merged certificate. 1736 13.6. Global Append-only Ledgers ("Blockchain") 1738 The append-only aspect of some OpenPGP keystores encourages a user of 1739 the keystore to rely on that keystore as a faithful reporter of 1740 history, and one that will not misrepresent or hide the history that 1741 they know about. An unfaithful "append-only" keystore could abuse 1742 the trust in a number of ways, including withholding revocation 1743 certificates, offering different sets of certificates to different 1744 clients doing certificate lookup, and so on. 1746 However, the most widely used append-only OpenPGP keystore, the [SKS] 1747 keyserver pool, offers no cryptographically verifiable guarantees 1748 that it will actually remain append-only. Users of the pool have 1749 traditionally relied on its distributed nature, and the presumption 1750 that coordination across a wide range of administrators would make it 1751 difficult for the pool to reliably lie or omit data. However, the 1752 endpoint most commonly used by clients to access the network is 1753 "hkps://hkps.pool.sks-keyservers.net", the default for [GnuPG]. That 1754 endpoint is increasingly consolidated, and currently consists of 1755 hosts operated by only two distinct administrators, increasing the 1756 risk of potential misuse. 1758 Offering cryptographic assurances that a keystore could remain 1759 append-only is an appealing prospect to defend against these kinds of 1760 attack. Many popular schemes for providing such assurances are known 1761 as "blockchain" technologies, or global append-only ledgers. 1763 With X.509 certificates, we have a semi-functional Certificate 1764 Transparency ([RFC6962], or "CT") ecosystem that is intended to 1765 document and preserve evidence of (mis)issuance by well-known 1766 certificate authorities (CAs), which implements a type of global 1767 append-only ledger. While the CT infrastructure remains vulnerable 1768 to certain combinations of colluding actors, it has helped to 1769 identify and sanction some failing CAs. 1771 Like other global append-only ledgers, CT itself is primarily a 1772 detection mechanism, and has no enforcement regime. If a widely-used 1773 CA were identified by certificate transparency to be untrustworthy, 1774 the rest of the ecosystem still needs to figure out how to impose 1775 sanctions or apply a remedy, which may or may not be possible. 1777 CT also has privacy implications - the certificates published in the 1778 CT logs are visible to everyone, for the lifetime of the log. 1780 For spam abatement, CT logs decline all X.509 certificates except 1781 those issued by certain CAs (those in popular browser "root stores"). 1782 This is an example of the strategy outlined in Section 4.9). 1784 Additional projects that provide some aspects of global append-only 1785 ledgers that try to address some of the concerns described here 1786 include [KEY-TRANSPARENCY] and [CONIKS], though they are not specific 1787 to OpenPGP. Both of these systems are dependent on servers operated 1788 by identity providers, however. And both offer the ability to detect 1789 a misbehaving identity provider, but no specific enforcement or 1790 recovery strategies against such an actor. 1792 It's conceivable that a keystore could piggyback on the CT logs or 1793 other blockchain/ledger mechanisms like [BITCOIN] to store 1794 irrevocable pieces of data (such as revocation certificates). 1795 Further work is needed to describe how to do this in an effective and 1796 performant way. 1798 13.7. Certificate Lookup for Identity Monitoring 1800 A typical use case for certificate lookup is a user looking for a 1801 certificate in order to be able to encrypt an outbound message 1802 intended for a given e-mail address, but this is not the only use 1803 case. 1805 Another use caes is when the party in control of a particular 1806 identity wants to determine whether anyone else is claiming that 1807 identity. That is, a client in control of the secret key material 1808 associated with a particular certificate with user ID X might search 1809 a keystore for all certificates matching X in order to find out 1810 whether any other certificates claim it. 1812 This is an important safeguard as part of the ledger-based detection 1813 mechanisms described in Section 13.6, but may also be useful for 1814 keystores in general. 1816 However, identity monitoring against a keystore that does not defend 1817 against user ID flooding (Section 2.2) is expensive and potentially 1818 of limited value. In particular, a malicious actor with a 1819 certificate which duplicates a given User ID could flood the keystore 1820 with similar certificates, hiding whichever one is in malicious use. 1822 Since such a keystore is not considered authoritative by any 1823 reasonable client for the user ID in question, this attack forces the 1824 identity-monitoring defender to spend arbitrary resources fetching 1825 and evaluating each certificate in the flood, without knowing which 1826 certificate other clients might be evaluating. 1828 14. OpenPGP details 1830 This section collects details about common OpenPGP implementation 1831 behavior that are useful in evaluating and reasoning about OpenPGP 1832 certificates. 1834 14.1. Revocations 1836 It's useful to classify OpenPGP revocations of key material into two 1837 categories: "soft" and "hard". 1839 If the "Reason for Revocation" of an OpenPGP key is either "Key is 1840 superseded" or "Key is retired and no longer used", it is a "soft" 1841 revocation. 1843 An implementation that interprets a "soft" revocation will typically 1844 not invalidate signatures made by the associated key with a creation 1845 date that predates the date of the soft revocation. A "soft" 1846 revocation in some ways behaves like a non-overridable expiration 1847 date. 1849 All other revocations of OpenPGP keys (with any other Reason for 1850 Revocation, or with no Reason for Revocation at all) should be 1851 considered "hard". 1853 The presence of a "hard" revocation of an OpenPGP key indicates that 1854 the user should reject all signatures and certifications made by that 1855 key, regardless of the creation date of the signature. 1857 Note that some OpenPGP implementations do not distinguish between 1858 these two categories. 1860 A defensive OpenPGP implementation that does not distinguish between 1861 these two categories SHOULD treat all revocations as "hard". 1863 An implementation aware of a "soft" revocation or of key or 1864 certificate expiry at time T SHOULD accept and process a "hard" 1865 revocation even if it appears to have been issued at a time later 1866 than T. 1868 14.2. User ID Conventions 1870 [RFC4880] requires a user ID to be a UTF-8 string, but does not 1871 constrain it beyond that. In practice, a handful of conventions 1872 predominate in how User IDs are formed. 1874 The most widespread convention is a "name-addr" as defined in 1875 [RFC5322]. For example: 1877 Alice Jones 1879 But a growing number of OpenPGP certificates contain user IDs that 1880 are instead a raw [RFC5322] "addr-spec", omitting the "display-name" 1881 and the angle brackets entirely, like so: 1883 alice@example.org 1885 Some certificates have user IDs that are simply normal human names 1886 (perhaps "display-name" in [RFC5322] jargon, though not necessarily 1887 conforming to a specific ABNF). For example: 1889 Alice Jones 1891 Still other certificates identify a particular network service by 1892 scheme and hostname. For example, the administrator of an ssh host 1893 participating in the [MONKEYSPHERE] might choose a user ID for the 1894 OpenPGP representing the host like so: 1896 ssh://foo.example.net 1898 14.3. E-mail Address Canonicalization 1900 When an OpenPGP user IDs includes an "addr-spec", there still may be 1901 multiple ways of representing the addr-spec that refer to the same 1902 underlying mailbox. Having a truly canonical form of an "addr-spec" 1903 is probably impossible because of legacy deployments of mailservers 1904 that do odd things with the local part, but e-mail addresses used in 1905 an abuse-resistant ecosystem SHOULD be constrained enough to admit to 1906 some sensible form of canonicalization. 1908 14.3.1. Disallowing Non-UTF-8 Local Parts 1910 In [RFC5322], the "local-part" can be any "dot-atom". But if this is 1911 [RFC2047] decoded, it could be any arbitrary charset, not necessarily 1912 UTF-8. FIXME: Do we convert from the arbitrary charset to UTF-8? 1914 14.3.2. Domain Canonicalization 1916 FIXME: should domain name be canonicalized into punycode form? User 1917 IDs are typically user-facing, so i think the canonicalized form 1918 should be the [UNICODE-NORMALIZATION] Form C (NFC) of the domain 1919 name. Can we punt to some other draft here? 1921 14.3.3. Local Part Canonicalization 1923 FIXME: [I-D.koch-openpgp-webkey-service] recommends downcasing all 1924 ASCII characters in the left-hand side, but leaves all 1926 15. Security Considerations 1928 This document offers guidance on mitigating a range of denial-of- 1929 service attacks on public keystores, so the entire document is in 1930 effect about security considerations. 1932 Many of the mitigations described here defend individual OpenPGP 1933 certificates against flooding attacks (see Section 2.1). But only 1934 some of these mitigations defend against flooding attacks against the 1935 keystore itself (see Section 2.4), or against flooding attacks on the 1936 space of possible user IDs (see Section 2.2). Thoughtful threat 1937 modeling and monitoring of the keystore and its defenses are probably 1938 necessary to maintain the long-term health of the keystore. 1940 Section 13.1 describes a potentially scary security problem for 1941 designated revokers. 1943 TODO (more security considerations) 1945 15.1. Tension Between Unrestricted Uploads and Certificate Lookup 1947 Note that there is an inherent tension between accepting arbitrary 1948 certificate uploads and permitting effective certificate lookup. If 1949 a keystore accepts arbitrary certificate uploads for redistribution, 1950 it appears to be vulnerable to user ID flooding (Section 2.2), which 1951 makes it difficult or impossible to rely on for certificate lookup. 1953 In the broader ecosystem, it may be necessary to use gated/controlled 1954 certificate lookup mechanisms. For example, both 1955 [I-D.koch-openpgp-webkey-service] and [RFC7929] enable the 1956 administrator of a DNS domain to distribute certificates associated 1957 with e-mail addresses within that domain, while excluding other 1958 parties. As a rather different example, [I-D.mccain-keylist] offers 1959 certificate lookup on the basis of interest - a client interested in 1960 an organization can use that mechanism to learn what certificates 1961 that organization thinks are worth knowing about, associated with a 1962 range of identities regardless of the particular DNS domain. Note 1963 that [I-D.mccain-keylist] does not provide the certificates directly, 1964 but instead expects the client to be able to retrieve them by primary 1965 key fingerprint through some other keystore capable of (and 1966 responsible for) certificate update. 1968 16. Privacy Considerations 1970 Keystores themselves raise a host of potential privacy concerns. 1971 Additional privacy concerns are raised by traffic to and from the 1972 keystores. This section tries to outline some of the risks to the 1973 privacy of people whose certificates are stored and redistributed in 1974 public keystores, as well as risks to the privacy of people who make 1975 use of the key stores for certificate lookup, certificate discovery, 1976 or certificate update. 1978 16.1. Publishing Identity Information 1980 Public OpenPGP keystores often distribute names or e-mail addresses 1981 of people. Some people do not want their names or e-mail addresses 1982 distributed in a public keystore, or may change their minds about it 1983 at some point. Append-only keystores are particularly problematic in 1984 that regard. The mitigation in Section 7.4 can help such users strip 1985 their details from keys that they control. However, if an OpenPGP 1986 certificate with their details is uploaded to a keystore, but is not 1987 under their control, it's unclear what mechanisms can be used to 1988 remove the certificate that couldn't also be exploited to take down 1989 an otherwise valid certificate. 1991 Some jurisdictions may present additional legal risk for keystore 1992 operators that distribute names or e-mail addresses of non-consenting 1993 parties. 1995 Updates-only keystores (Section 8) and user ID redacting keystores 1996 (Section 5.1) may reduce this particular privacy concern because they 1997 distribute no user IDs at all. 1999 16.2. Social Graph 2001 Third-party certifications effectively map out some sort of social 2002 graph. A certification asserts a statement of belief by the issuer 2003 that the real-world party identified by the user ID is in control of 2004 the subject cryptographic key material. But those connections may be 2005 potentially sensitive, and some people may not want these maps built. 2007 A first-party-only keyserver (Section 9) avoids this privacy concern 2008 because it distributes no third-party privacy concern. 2010 First-party attested third-party certifications described in 2011 Section 10 are even more relevant edges in the social graph, because 2012 their bidirectional nature suggests that both parties are aware of 2013 each other, and see some value in mutual association. 2015 16.3. Tracking Clients by Queries 2017 Even without third-party certifications, the acts of certificate 2018 lookup, certificate discovery, and certificate update represent a 2019 potential privacy risk, because the keystore queried gets to learn 2020 which user IDs (in the case of lookup) or which certificates (in the 2021 case of update or discovery) the client is interested in. In the 2022 case of certificate update, if a client attempts to update all of its 2023 known certificates from the same keystore, that set is likely to be a 2024 unique set, and therefore identifies the client. A keystore that 2025 monitors the set of queries it receives might be able to profile or 2026 track those clients who use it repeatedly. 2028 A privacy-aware client which wants to to avoid such a tracking attack 2029 MAY try to perform certificate update from multiple different 2030 keystores. To hide network location, a client making a network query 2031 to a keystore SHOULD use an anonymity network like [TOR]. Tools like 2032 [PARCIMONIE] are designed to facilitate this type of certificate 2033 update. Such a client SHOULD also decline to use protocol features 2034 that permit linkability across interactions with the same keystore, 2035 such as TLS session resumption, HTTP cookies, and so on. 2037 Keystores which permit public access and want to protect the privacy 2038 of their clients SHOULD NOT reject access from clients using [TOR] or 2039 comparable anonymity networks. Additionally, they SHOULD minimize 2040 access logs they retain. 2042 Alternately, some keystores may distribute their entire contents to 2043 any interested client, in what can be seen as the most trivial form 2044 of private information retrieval. [DEBIAN-KEYRING] is one such 2045 example; its contents are distributed as an operating system package. 2046 Clients can interrogate their local copy of such a keystore without 2047 exposing their queries to a third-party. 2049 16.4. "Live" Certificate Validation Leaks Client Activity 2051 If a client relies on a keystore's certificate validation interface, 2052 or on the presence of a certificate in a keystore as a part of its 2053 validation calculations, it's unclear how long the assertion from the 2054 keystore is or should be considered to hold. One seemingly simple 2055 approach is to simply query the keystore's validation interface each 2056 time that the client needs to validate the certificate. 2058 This "live" validation approach poses a quandary to the client in the 2059 event that the keystore is unavailable. How should in interpret the 2060 "unknown" result? In addition, live validation reveals the client's 2061 activity to the keystore with fine precision. 2063 A privacy-aware client that depends on keystores for certificate 2064 validation SHOULD NOT perform "live" certificate validation on each 2065 use it makes of the certificate. Rather, it SHOULD cache the 2066 validation information for some period of time and make use of the 2067 cached copy where possible. If such a client does a regular 2068 certificate update from the same keystore, it SHOULD also pre- 2069 emptively query the keystore for certificate validation at the same 2070 time. 2072 Choosing the appropriate time intervals for this kind of caching has 2073 implications for the windows of risk for the client that might use a 2074 revoked certificate. Defining an appropriate schedule to make this 2075 tradeoff is beyond the scope of this document. 2077 16.5. Certificate Discovery Leaks Client Activity 2079 The act of doing certificate discovery on unknown signatures offers a 2080 colluding keystore and remote peer a chance to track a client's 2081 consumption of a given signature. 2083 An attacker with access to keystore logs could sign a message with a 2084 unique key, and then watch the keystore activity to determine when a 2085 client consumes the signature. This is potentially a tracking or 2086 "phone-home" situation. 2088 A signer that has no interest in this particular form of tracking can 2089 mitigate this concern by shipping their certificate in-band, 2090 alongside the signature, as recommended in Section 13.3. 2092 A privacy-aware client MAY insist on in-band certificates by 2093 declining to use any certificate discovery interface at all, and 2094 treat a bare signature by an unknown certificate as an invalid 2095 signature. 2097 16.6. Certificate Update Leaks Client Activity 2099 The act of doing certificate update itself reveals some information 2100 that the client is interested in a given certificate and how it may 2101 have changed since the last time the client updated it, or since it 2102 was first received by the client. 2104 This is essentially the same privacy problem presented by OCSP 2105 [RFC6960] in the X.509 world. In the online world of TLS, this 2106 privacy leak is mitigated by the CertificateStatus TLS handshake 2107 extension ([RFC4366]), a.k.a. "OCSP stapling". There is no 2108 comparable solution for the store-and-forward or non-online scenarios 2109 where OpenPGP is often found. 2111 Privacy-aware clients MAY prefer to access update interfaces from 2112 anonymity-preserving networks like [TOR] to obscure where they are on 2113 the network, but if the certificate being updated is known to be used 2114 only by a single client that may not help. 2116 Privacy-aware clients MAY prefer to stage their certificate updates 2117 over time, but longer delays imply greater windows of vulnerability 2118 for use of an already-revoked certificate. This strategy also does 2119 not help when a previously-unknown certificate is encountered in-band 2120 (see Section 13.3), and the OpenPGP client wants to evaluate it for 2121 use in the immediate context. 2123 16.7. Distinct Keystore Interfaces Leak Client Context and Intent 2125 The distinct keystore interfaces documented in Section 3 offer subtly 2126 different semantics, and are used by a reasonable keystore client at 2127 different times. A keystore that offers distinct discovery and 2128 update interfaces may infer that a client visiting the update 2129 interface already knows about the certificate in question, or that a 2130 client visiting the discovery interface is in the process of 2131 verifying a signature from a certificate it has not seen before. 2133 HKP itself ([I-D.shaw-openpgp-hkp]) conflates these two interfaces - 2134 the same HKP query is be used to perform both discovery and update 2135 (though implementations like [SKS] are not at all abuse-resistant for 2136 either use), which may obscure the context and intent of the client 2137 from the keystore somewhat. 2139 A privacy-aware client that can afford the additional bandwidth and 2140 complexity MAY use the keystore's discovery interface for both update 2141 and discovery, since the discovery interface is a proper superset of 2142 the update interface. 2144 16.8. Cleartext Queries 2146 If access to the keystore happens over observable channels (e.g., 2147 cleartext connections over the Internet), then a passive network 2148 monitor could perform the same type profiling or tracking attack 2149 against clients of the keystore described in Section 16.3. Keystores 2150 which offer network access SHOULD provide encrypted transport. 2152 16.9. Traffic Analysis 2154 Even if a keystore offers encrypted transport, the size of queries 2155 and responses may provide effective identification of the specific 2156 certificates fetched during lookup, discovery, or update, leaving 2157 open the types of tracking attacks described in Section 16.3. 2158 Clients of keystores SHOULD pad their queries to increase the size of 2159 the anonymity set. And keystores SHOULD pad their responses. 2161 The appropriate size of padding to effectively anonymize traffic to 2162 and from keystores is likely to be mechanism- and cohort-specific. 2163 For example, padding for keystores accessed via the DNS ([RFC7929] 2164 may use different padding strategies that padding for keystores 2165 accessed over WKD ([I-D.koch-openpgp-webkey-service]), which may in 2166 turn be different from keystores accessed over HKPS 2167 ([I-D.shaw-openpgp-hkp]). A keystore which only accepts user IDs 2168 within a specific domain (e.g., Section 4.3) or which uses custom 2169 process (Section 6.4) for verification might have different padding 2170 criteria than a keystore that serves the general public. 2172 Specific padding policies or mechanisms are out of scope for this 2173 document. 2175 17. User Considerations 2177 Section 10.2 describes some outstanding work that needs to be done to 2178 help users understand how to produce and distribute a third-party- 2179 certified OpenPGP certificate to an abuse-resistant keystore. 2181 Additionally, some keystores present directly user-facing 2182 affordances. For example, [SKS] keyservers typically offer forms and 2183 listings that can be viewed directly in a web browser. Such a 2184 keystore SHOULD be as clear as possible about what abuse mitigations 2185 it takes (or does not take), to avoid user confusion. 2187 Keystores which do not expect to be used directly as part of a 2188 certificate validation calculation SHOULD advise clients as 2189 explicitly as possible that they offer no assertions of validity. 2191 Experience with the [SKS] keyserver network shows that many users 2192 treat the keyserver web interfaces as authoritative. That is, users 2193 act as though the keyserver network offers some type of certificate 2194 validation. Unfortunately, The developer and implementor communities 2195 explicitly disavow any authoritative role in the ecosystem, and the 2196 implementations attempt very few mitigations against abuse, 2197 permitting redistribution of even cryptographically invalid OpenPGP 2198 packets. Clearer warnings to end users might reduce this kind of 2199 misperception. Or the community could encourage the removal of 2200 frequently misinterpreted user interfaces entirely. 2202 18. IANA Considerations 2204 This document asks IANA to register two entries in the OpenPGP 2205 Notation IETF namespace, both with a reference to this document: 2207 o the "ksok" notation is defined in Section 10. 2209 o the "uidhash" notation is defined in Section 5.1.4. 2211 19. Document Considerations 2213 [ RFC Editor: please remove this section before publication ] 2215 This document is currently edited as markdown. Minor editorial 2216 changes can be suggested via merge requests at 2217 https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore or by 2218 e-mail to the author. Please direct all significant commentary to 2219 the public IETF OpenPGP mailing list: openpgp@ietf.org 2221 19.1. Document History 2223 substantive changes between -02 and -03: 2225 o new sections: 2227 * Keystore Interfaces 2228 * Keystore Client Best Practices 2230 * Certificate Generation and Management Best Practices 2232 o rename "certificate discovery" to "certificate lookup" 2234 o redefine "certificate discovery" to refer to lookup by signing 2235 (sub)key 2237 o new attack: fingerprint flooding 2239 o new retrieval-time mitigations - tighter filters on discovery and 2240 update 2242 o recommend in-band certificates where possible to avoid discovery 2243 and lookup 2245 o new privacy considerations: 2247 * distinct keystore interfaces 2249 * certificate update 2251 * certificate discovery 2253 * certificate validation 2255 o more nuance about unhashed subpacket filtering 2257 substantive changes between -01 and -02: 2259 o distinguish different forms of flooding attack 2261 o distinguish toxic data as distinct from flooding 2263 o retrieval-time mitigations 2265 o user ID redaction 2267 o references to related work (CT, keylist, CONIKS, key transparency, 2268 ledgers/"blockchain", etc) 2270 o more details about UI/UX 2272 substantive changes between -00 and -01: 2274 o split out Contextual and Non-Append-Only mitigations 2275 o documented several other mitigations, including: 2277 * Decline Data From the Future 2279 * Blocklist 2281 * Exterior Process 2283 * Designated Authorities 2285 * Known Certificates 2287 * Rate-Limiting 2289 * Scoped User IDs 2291 o documented Updates-Only Keystores 2293 o consider three different kinds of flooding 2295 o deeper discussion of privacy considerations 2297 o better documentation of Reason for Revocation 2299 o document user ID conventions 2301 20. Acknowledgements 2303 This document is the result of years of operational experience and 2304 observation, as well as conversations with many different people - 2305 users, implementors, keystore operators, etc. A non-exhaustive list 2306 of people who have contributed ideas or nuance to this document 2307 specifically includes: 2309 o Antoine Beaupre 2311 o ilf 2313 o Jamie McClelland 2315 o Jonathan McDowell 2317 o Justus Winter 2319 o Marcus Brinkmann 2321 o Micah Lee 2322 o Neal Walfield 2324 o Phil Pennock 2326 o Philihp Busby 2328 o vedaal 2330 o Vincent Breitmoser 2332 o Wiktor Kwapisiewicz 2334 21. References 2336 21.1. Normative References 2338 [I-D.ietf-openpgp-rfc4880bis] 2339 Koch, W., carlson, b., Tse, R., and D. Atkins, "OpenPGP 2340 Message Format", draft-ietf-openpgp-rfc4880bis-06 (work in 2341 progress), November 2018. 2343 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 2344 Part Three: Message Header Extensions for Non-ASCII Text", 2345 RFC 2047, DOI 10.17487/RFC2047, November 1996, 2346 . 2348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2349 Requirement Levels", BCP 14, RFC 2119, 2350 DOI 10.17487/RFC2119, March 1997, 2351 . 2353 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2354 Thayer, "OpenPGP Message Format", RFC 4880, 2355 DOI 10.17487/RFC4880, November 2007, 2356 . 2358 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2359 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2360 May 2017, . 2362 21.2. Informative References 2364 [AUTOCRYPT] 2365 Breitmoser, V., Krekel, H., and D. Gillmor, "Autocrypt - 2366 Convenient End-to-End Encryption for E-Mail", n.d., 2367 . 2369 [BITCOIN] "Bitcoin", n.d., . 2371 [CONIKS] Felten, E., Freedman, M., Melara, M., Blankstein, A., and 2372 J. Bonneau, "CONIKS Key Management System", n.d., 2373 . 2375 [DEBIAN-KEYRING] 2376 McDowell, J., "Debian Keyring", n.d., 2377 . 2379 [GnuPG] Koch, W., "Using the GNU Privacy Guard", n.d., 2380 . 2382 [I-D.koch-openpgp-webkey-service] 2383 Koch, W., "OpenPGP Web Key Directory", draft-koch-openpgp- 2384 webkey-service-07 (work in progress), November 2018. 2386 [I-D.mccain-keylist] 2387 McCain, R., Lee, M., and N. Welch, "Distributing OpenPGP 2388 Key Fingerprints with Signed Keylist Subscriptions", 2389 draft-mccain-keylist-04 (work in progress), March 2019. 2391 [I-D.shaw-openpgp-hkp] 2392 Shaw, D., "The OpenPGP HTTP Keyserver Protocol (HKP)", 2393 draft-shaw-openpgp-hkp-00 (work in progress), March 2003. 2395 [KEY-TRANSPARENCY] 2396 Belvin, G. and R. Hurst, "Key Transparency, a transparent 2397 and secure way to look up public keys", n.d., 2398 . 2400 [MAILVELOPE-KEYSERVER] 2401 Oberndoerfer, T., "Mailvelope Keyserver", n.d., 2402 . 2404 [MONKEYSPHERE] 2405 Gillmor, D. and J. Rollins, "Monkeysphere", n.d., 2406 . 2408 [PARCIMONIE] 2409 Intrigeri, ., "Parcimonie", n.d., 2410 . 2413 [PGP-GLOBAL-DIRECTORY] 2414 Symantec Corporation, "PGP Global Directory Key 2415 Verification Policy", 2011, 2416 . 2419 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 2420 and T. Wright, "Transport Layer Security (TLS) 2421 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 2422 . 2424 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2425 DOI 10.17487/RFC5322, October 2008, 2426 . 2428 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 2429 Galperin, S., and C. Adams, "X.509 Internet Public Key 2430 Infrastructure Online Certificate Status Protocol - OCSP", 2431 RFC 6960, DOI 10.17487/RFC6960, June 2013, 2432 . 2434 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 2435 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 2436 . 2438 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 2439 (DANE) Bindings for OpenPGP", RFC 7929, 2440 DOI 10.17487/RFC7929, August 2016, 2441 . 2443 [SKS] Minsky, Y., Fiskerstrand, K., and P. Pennock, "SKS 2444 Keyserver Documentation", March 2018, 2445 . 2448 [TOR] "The Tor Project", n.d., . 2450 [UNICODE-NORMALIZATION] 2451 Whistler, K., "Unicode Normalization Forms", February 2452 2019, . 2454 Author's Address 2456 Daniel Kahn Gillmor 2457 American Civil Liberties Union 2458 125 Broad St. 2459 New York, NY 10004 2460 USA 2462 Email: dkg@fifthhorseman.net