idnits 2.17.1 draft-dkg-openpgp-abuse-resistant-keystore-04.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 1148 has weird spacing: '...ct (by remov...' == Line 1151 has weird spacing: '..., this remov...' == Line 1152 has weird spacing: '... any signat...' == Line 1153 has weird spacing: '...revoked signa...' -- The document date (August 22, 2019) is 1709 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-07 == Outdated reference: A later version (-17) exists of draft-koch-openpgp-webkey-service-08 == 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 August 22, 2019 5 Expires: February 23, 2020 7 Abuse-Resistant OpenPGP Keystores 8 draft-dkg-openpgp-abuse-resistant-keystore-04 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 February 23, 2020. 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 Refresh . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 18 101 5.1.1. Certificate Refresh 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 Refresh . . . . . . . . . . 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 . . . . . . 24 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. Primary Key Sovereignty . . . . . . . . . . . . . . . . . . . 27 121 8.1. Refresh-only Keystores . . . . . . . . . . . . . . . . . 27 122 8.2. First-party-only Keystores . . . . . . . . . . . . . . . 28 123 8.2.1. First-party-only Without User IDs . . . . . . . . . . 29 124 8.3. First-party-attested Third-party Certifications . . . . . 29 125 8.3.1. Client Interactions . . . . . . . . . . . . . . . . . 30 126 8.3.2. Attestation Revocations . . . . . . . . . . . . . . . 31 127 8.3.3. Distribution of Attestation Revocations . . . . . . . 32 128 8.3.4. Revoking Third-party Certifications . . . . . . . . . 33 129 9. Keystore Client Best Practices . . . . . . . . . . . . . . . 35 130 9.1. Use Constrained Keystores for Lookup . . . . . . . . . . 35 131 9.2. Normalize Addresses and User IDs for Lookup . . . . . . . 35 132 9.3. Avoid Fuzzy Lookups . . . . . . . . . . . . . . . . . . . 36 133 9.4. Prefer Full Fingerprint for Discovery and Refresh . . . . 36 134 9.5. Use Caution with Keystore-provided Validation . . . . . . 36 135 10. Certificate Generation and Management Best Practices . . . . 37 136 10.1. Canonicalized E-Mail Addresses . . . . . . . . . . . . . 37 137 10.2. Normalized User IDs . . . . . . . . . . . . . . . . . . 37 138 10.3. Avoid Large User Attributes . . . . . . . . . . . . . . 37 139 10.4. Provide Cross-Sigs . . . . . . . . . . . . . . . . . . . 37 140 10.5. Provide Issuer Fingerprint Subpackets . . . . . . . . . 38 141 10.6. Put Cross-Sigs and Issuer Fingerprint in Hashed 142 Subpackets . . . . . . . . . . . . . . . . . . . . . . . 38 143 10.7. Submit Certificates to Restricted, Lookup-Capable 144 Keystores . . . . . . . . . . . . . . . . . . . . . . . 38 145 11. Side Effects and Ecosystem Impacts . . . . . . . . . . . . . 38 146 11.1. Designated Revoker . . . . . . . . . . . . . . . . . . . 38 147 11.2. Key IDs vs. Fingerprints in Certificate Discovery . . . 39 148 11.3. In-band Certificates . . . . . . . . . . . . . . . . . . 39 149 11.3.1. In-band Certificate Minimization and Validity . . . 40 150 11.4. Certification-capable Subkeys . . . . . . . . . . . . . 41 151 11.5. Assessing Certificates in the Past . . . . . . . . . . . 41 152 11.5.1. Point-in-time Certificate Evaluation . . . . . . . . 41 153 11.5.2. Signature Verification and Non-append-only Keystores 42 154 11.6. Global Append-only Ledgers ("Blockchain") . . . . . . . 42 155 11.7. Certificate Lookup for Identity Monitoring . . . . . . . 43 156 12. OpenPGP details . . . . . . . . . . . . . . . . . . . . . . . 44 157 12.1. Revocations . . . . . . . . . . . . . . . . . . . . . . 44 158 12.2. User ID Conventions . . . . . . . . . . . . . . . . . . 45 159 12.3. E-mail Address Canonicalization . . . . . . . . . . . . 46 160 12.3.1. Disallowing Non-UTF-8 Local Parts . . . . . . . . . 46 161 12.3.2. Domain Canonicalization . . . . . . . . . . . . . . 46 162 12.3.3. Local Part Canonicalization . . . . . . . . . . . . 46 163 13. Security Considerations . . . . . . . . . . . . . . . . . . . 46 164 13.1. Tension Between Unrestricted Uploads and Certificate 165 Lookup . . . . . . . . . . . . . . . . . . . . . . . . . 47 166 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 47 167 14.1. Publishing Identity Information . . . . . . . . . . . . 47 168 14.2. Social Graph . . . . . . . . . . . . . . . . . . . . . . 48 169 14.3. Tracking Clients by Queries . . . . . . . . . . . . . . 48 170 14.4. "Live" Certificate Validation Leaks Client Activity . . 49 171 14.5. Certificate Discovery Leaks Client Activity . . . . . . 49 172 14.6. Certificate Refresh Leaks Client Activity . . . . . . . 50 173 14.7. Distinct Keystore Interfaces Leak Client Context and 174 Intent . . . . . . . . . . . . . . . . . . . . . . . . . 50 175 14.8. Cleartext Queries . . . . . . . . . . . . . . . . . . . 51 176 14.9. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 51 177 15. User Considerations . . . . . . . . . . . . . . . . . . . . . 51 178 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 179 17. Document Considerations . . . . . . . . . . . . . . . . . . . 52 180 17.1. Document History . . . . . . . . . . . . . . . . . . . . 52 181 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 182 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 183 19.1. Normative References . . . . . . . . . . . . . . . . . . 55 184 19.2. Informative References . . . . . . . . . . . . . . . . . 56 185 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 58 187 1. Introduction 189 1.1. Requirements Language 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 193 "OPTIONAL" in this document are to be interpreted as described in BCP 194 14 [RFC2119] [RFC8174] when, and only when, they appear in all 195 capitals, as shown here. 197 1.2. Terminology 199 o "OpenPGP certificate" (or just "certificate") is used 200 interchangeably with [RFC4880]'s "Transferable Public Key". The 201 term "certificate" refers unambiguously to the entire composite 202 object, unlike "key", which might also be used to refer to a 203 primary key or subkey. 205 o An "identity certification" (or just "certification") is an 206 [RFC4880] signature packet that covers OpenPGP identity 207 information - that is, any signature packet of type 0x10, 0x11, 208 0x12, or 0x13. Certifications are said to (try to) "bind" a 209 primary key to a User ID. 211 o The primary key that makes the certification is known as the 212 "issuer". The primary key over which the certification is made is 213 known as the "subject". 215 o A "first-party certification" is issued by the primary key of a 216 certificate, and binds itself to a user ID in the certificate. 217 That is, the issuer is the same as the subject. This is sometimes 218 referred to as a "self-sig". 220 o A "third-party certification" is a made over a primary key and 221 user ID by some other certification-capable primary key. That is, 222 the issuer is different than the subject. The elusive "second- 223 party" is presumed to be the verifier who is trying to interpret 224 the certificate. 226 o All subkeys are bound to the primary key with an [RFC4880] Subkey 227 Binding Signature. Some subkeys also reciprocate by binding 228 themselves back to the primary key with an [RFC4880] Primary Key 229 Binding Signature. The Primary Key Binding Signature is also 230 known as a "cross-signature" or "cross-sig". 232 o A "keystore" is any collection of OpenPGP certificates. Keystores 233 typically receive mergeable updates over the course of their 234 lifetime which might add to the set of OpenPGP certificates they 235 hold, or update the certificates. 237 o "Certificate validation" is the process whereby a user decides 238 whether a given user ID in an OpenPGP certificate is acceptable 239 for use. For example, if the certificate has a user ID of "Alice 240 " and the user wants to send an e-mail to 241 "alice@example.org", the mail user agent might want to ensure that 242 the certificate is valid for this e-mail address before encrypting 243 to it. Some clients may rely on specific keystores for 244 certificate validation, but some keystores (e.g., [SKS]) make no 245 assertions whatsoever about certificate validity, and others offer 246 only very subtle guarantees. See Section 3.4 for more details. 248 o "Certificate lookup" refers to the retrieval of a set of 249 certificates from a keystore based on the user ID or some 250 substring match of the user ID. See Section 3.3 for more details. 252 o "Certificate refresh" refers to retrieval of a certificate from a 253 keystore based on the fingerprint of the primary key. See 254 Section 3.1 for more details. 256 o "Certificate discovery" refers to the retrieval of a set of 257 certificates from a keystore based on the fingerprint or key ID of 258 any key in the certificate. See Section 3.2 for more details. 260 o A "keyserver" is a particular kind of keystore, typically a means 261 of publicly distributing OpenPGP certificates or updates to them. 262 Examples of keyserver software include [SKS] and 263 [MAILVELOPE-KEYSERVER]. One common HTTP interface for keyservers 264 is [I-D.shaw-openpgp-hkp]. 266 o A "synchronizing keyserver" is a keyserver which gossips with 267 other peers, and typically acts as an append-only log. Such a 268 keyserver is typically useful for certificate lookup, certificate 269 discovery, and certificate refresh (including revocation 270 information). They are typically _not_ useful for certificate 271 validation, since they make no assertions about whether the 272 identities in the certificates they server are accurate. As of 273 the writing of this document, [SKS] is the canonical synchronizing 274 keyserver implementation, though other implementations exist. 276 o An "e-mail validating keyserver" is a keyserver which attempts to 277 verify the identity in an OpenPGP certificate's user ID by 278 confirming access to the e-mail account, and optionally by 279 confirming access to the secret key. Some implementations permit 280 removal of a certificate by anyone who can prove access to the 281 e-mail address in question. They are useful for certificate 282 lookup based on e-mail address and certificate validation (by 283 users who trust the operator), but some may not be useful for 284 certificate refresh or certificate discovery, since a certificate 285 could be simply replaced by an adversary who also has access to 286 the e-mail address in question. [MAILVELOPE-KEYSERVER] is an 287 example of such a keyserver. 289 o A "sovereignty-respecting" keystore is one that only distributes 290 data associated with a given certificate that has been explicitly 291 approved by the primary key of that certificate. See Section 8 292 for more details and example strategies. 294 o "Cryptographic validity" refers to mathematical evidence that a 295 signature came from the secret key associated with the public key 296 it claims to come from. Note that a certification may be 297 cryptographically valid without the signed data being true (for 298 example, a given certificate with the user ID "Alice 299 " might not belong to the person who controls 300 the e-mail address "alice@example.org" even though the self-sig is 301 cryptographically valid). In particular, cryptographic validity 302 for user ID in a certificate is typically insufficient evidence 303 for certificate validation. Also note that knowledge of the 304 public key of the issuer is necessary to determine whether any 305 given signature is cryptographically valid. Some keyservers 306 perform cryptographic validation in some contexts. Other 307 keyservers (like [SKS]) perform no cryptographic validation 308 whatsoever. 310 o OpenPGP revocations can have "Reason for Revocation" (see 311 [RFC4880]), which can be either "soft" or "hard". The set of 312 "soft" reasons is: "Key is superseded" and "Key is retired and no 313 longer used". All other reasons (and revocations that do not 314 state a reason) are "hard" revocations. See Section 12.1 for more 315 detail. 317 2. Problem Statement 319 OpenPGP keystores that handle submissions from the public are subject 320 to a range of attacks by malicious submitters. 322 This section describes five distinct attacks that public keystores 323 should consider. 325 2.1. Certificate Flooding 327 Many public keystores (including both the [SKS] keyserver network and 328 [MAILVELOPE-KEYSERVER]) allow anyone to attach arbitrary data (in the 329 form of third-party certifications) to any certificate, bloating that 330 certificate to the point of being impossible to effectively retrieve. 331 For example, some OpenPGP implementations simply refuse to process 332 certificates larger than a certain size. 334 This kind of Denial-of-Service attack makes it possible to make 335 someone else's certificate unretrievable from the keystore, 336 preventing certificate lookup, discovery, or refresh. In the case of 337 a revoked certificate that has been flooded, this potentially leaves 338 the client of the keystore with the compromised certificate in an 339 unrevoked state locally because it was unable to fetch the revocation 340 information. 342 Additionally, even without malice, OpenPGP certificates can 343 potentially grow without bound. 345 2.2. User ID Flooding 347 Public keystores that are used for certificate lookup may also be 348 vulnerable to attacks that flood the space of known user IDs. In 349 particular, if the keystore accepts arbitrary certificates from the 350 public and does no verification of the user IDs, then any client 351 searching for a given user ID may need to review and process an 352 effectively unbounded set of maliciously-submitted certificates to 353 find the non-malicious certificates they are looking for. 355 For example, if an attacker knows that a given system consults a 356 keystore looking for certificates which match the e-mail address 357 "alice@example.org", the attacker may upload thousands of 358 certificates containing user IDs that match that address. Even if 359 those certificates would not be accepted by a client (e.g., because 360 they were not certified by a known-good authority), the client still 361 has to iterate through all of them in order to find the non-malicious 362 certificates. 364 User ID flooding is only effective if the keystore offers a lookup 365 interface at all. 367 2.3. Fingerprint Flooding 369 A malicious actor who wants to render a certificate unavailable for 370 refresh may generate an arbitrary number of OpenPGP certificates with 371 the targeted primary key attached as a subkey. If they can convince 372 a keystore to accept all of those certificates, and the keystore 373 returns them by subkey match during certificate refresh, then the 374 certificate refresh client will need to spend an arbitrary amount of 375 bandwidth and processing power filtering out the irrelevant data, and 376 may potentially give up before discovering the certificate of 377 interest. 379 A malicious actor may also want to confuse a certificate discovery 380 request that was targeted at a particular subkey, by binding that 381 subkey to multiple bogus certificates. If these bogus certificates 382 are ingested and redistributed by the keystore, then a certificate 383 discovery client may receive a set of certificates that cannot be 384 adequately distinguished. 386 2.4. Keystore Flooding 388 A public keystore that accepts arbitrary OpenPGP material and is 389 append-only is at risk of being overwhelmed by sheer quantity of 390 malicious uploaded packets. This is a risk even if the user ID space 391 is not being deliberately flooded, and if individual certificates are 392 protected from flooding by any of the mechanisms described later in 393 this document. 395 The keystore itself can become difficult to operate if the total 396 quantity of data is too large, and if it is a synchronizing 397 keyserver, then the quantities of data may impose unsustainable 398 bandwidth costs on the operator as well. 400 Effectively mitigating against keystore flooding requires either 401 abandoning the append-only property that some keystores prefer, or 402 imposing very strict controls on initial ingestion. 404 2.5. Toxic Data 406 Like any large public dataset, it's possible that a keystore ends up 407 hosting some content that is legally actionable in some 408 jurisdictions, including libel, child pornography, material under 409 copyright or other "intellectual property" controls, blasphemy, hate 410 speech, etc. 412 A public keystore that accepts and redistributes arbitrary content 413 may face risk due to uploads of toxic data. 415 3. Keystore Interfaces 417 Some keystores have simple interfaces, like files present in a local 418 filesystem. But many keystores offer an API for certificate 419 retrieval of different types. This section documents a set of useful 420 interactions that a client may have with such a keystore. 422 They are represented in abstract form, and are not intended to be the 423 full set of interfaces offered by any keystore, but rather a 424 convenient way to think about the operations that make the keystore 425 useful for its clients. 427 Not all keystores may offer all of these interfaces, or they may 428 offer them in subtly different forms, but clients will nevertheless 429 try to perform something like these operations with keystores that 430 they interact with. 432 3.1. Certificate Refresh 434 This is the simplest keystore operation. The client sends the 435 keystore the full fingerprint of the certificate's primary key, and 436 the keystore sends the client the corresponding certificate (or 437 nothing, if the keystore does not contain a certificate with a 438 matching primary key). 440 keystore.cert_refresh(primary_fpr) -> certificate? 442 A client uses certificate refresh to retrieve the full details of a 443 certificate that it already knows about. For example, it might be 444 interested in refreshs to the certificate known to the keystore, 445 including revocations, expiration refreshs, new third-party 446 certifications, etc. 448 Upon successful refresh, the client SHOULD merge the retrieved 449 certificate with its local copy. 451 Not all keystores offer this operation. For example, clients cannot 452 use WKD ([I-D.koch-openpgp-webkey-service]) or OPENPGPKEY ([RFC7929]) 453 for certificate refresh. 455 3.2. Certificate Discovery 457 If a client is aware of an OpenPGP signature or certification that it 458 cannot verify because it does not know the issuing certificate, it 459 may consult a keystore to try to discover the certificate based on 460 the Issuer or Issuer Fingerprint subpacket in the signature or 461 certification it is trying to validate. 463 keystore.cert_discovery(keyid|fpr) -> certificate_list 465 This is subtly different from certificate refresh (Section 3.1) in 466 three ways: 468 o it may return more than one certificate (e.g., when multiple 469 certificates share a subkey, or when a primary key on one 470 certificate is a subkey on another) 472 o it is willing to accept searches by short key ID, not just 473 fingerprint 475 o it is willing to match against a subkey, not just a primary key 477 While a certificate discovery client does not initially know the 478 certificate it is looking for, it's possible that the returned 479 certificate is one that the client already knows about. For example, 480 a new subkey may have been added to a certificate. 482 Upon successful discovery, the client SHOULD merge any retrieved 483 certificates with discovered local copies (as determined by primary 484 key), and then evaluate the original signature against any retrieved 485 certificate that appears to be valid and reasonable for use in the 486 signing context. 488 It is unclear what a client should do if multiple certificates do 489 appear to be valid for a given signature, because of ambiguity this 490 represents about the identity of the signer. However, this ambiguity 491 is similar to the ambiguity of a certificate with multiple valid user 492 IDs, which the client already needs to deal with. 494 Not all keystores offer this operation. For example, clients cannot 495 use WKD ([I-D.koch-openpgp-webkey-service]) or OPENPGPKEY ([RFC7929] 496 for certificate discovery. 498 3.3. Certificate Lookup 500 If a client wants to encrypt a message to a particular e-mail 501 address, or wants to encrypt a backup to some identity that it knows 502 of but does not have a certificate for, it may consult a keystore to 503 discover certificates that claim that identity in their user ID 504 packets. Both [I-D.koch-openpgp-webkey-service] and 505 [I-D.shaw-openpgp-hkp] offer certificate lookup mechanisms. 507 [RFC4880] User IDs are constrained only in that they are a UTF-8 508 string, but some conventions govern their practical use. See 509 Section 12.2 for more discussion of some common conventions around 510 user ID structure. 512 Note that lookup does not necessarily imply user ID or certificate 513 validation. It is entirely possible for a keystore to return a 514 certificate during lookup that the client cannot validate. 516 Abuse-resistant keystores that offer a lookup interface SHOULD 517 distinguish interfaces that perform full-string-match lookup from 518 interfaces that perform e-mail address based lookup. 520 3.3.1. Full User ID Lookup 522 The most straightforward form of certificate lookup asks for the set 523 of all certificates that contain a user ID that exactly and 524 completely matches the query parameter supplied by the client. 526 keystore.cert_lookup(uid) -> certificate_list 527 In its simplest form, this match is done by a simple bytestring 528 comparison. More sophisticated keystores MAY perform the comparison 529 after applying [UNICODE-NORMALIZATION] form NFC to both the "uid" 530 query and the user IDs from the stored certificates. 532 3.3.2. E-mail Address Lookup 534 However, some common use cases look for specific patterns in the user 535 ID rather than the entire user ID. Most useful to many existing 536 OpenPGP clients is a lookup by e-mail address. 538 keystore.cert_lookup(addr) -> certificate_list 540 For certificates with a user ID that matches the structure of an 541 [RFC5322] "name-addr" or "addr-spec", a keystore SHOULD extract the 542 "addr-spec" from the user ID, canonicalize it (see Section 12.3), and 543 compare it to the canonicalized form of of the "addr" query 544 parameter. 546 3.3.3. Other Lookup Mechanisms 548 Some keystores offer other forms of substring or regular expression 549 matching against the stored user IDs. These other forms of lookup 550 may be useful in some contexts (e.g., Section 11.7), but they may 551 also represent privacy concerns (e.g., Section 14.1), and they may 552 impose additional computational or indexing burdens on the keystore. 554 3.4. Certificate Validation 556 An OpenPGP client may assess certificate and user ID validity based 557 on many factors, some of which are directly contained in the 558 certificate itself (e.g., third-party certifications), and some of 559 which are based on the context known to the client, including: 561 o Whether it has seen e-mails from that address signed by that 562 certificate in the past, 564 o How long it has known about the certificate, 566 o Whether the certificate was fetched from a keystore that asserts 567 validity of the user ID or some part of it (such as the e-mail 568 address). 570 A keystore MAY facilitate clients pursuing this last point of 571 contextual corroboration via a direct interface: 573 keystore.cert_validate(primary_fpr, uid) -> boolean 574 In an e-mail-specific context, the client might only care about the 575 keystore's opinion about the validity of the certificate for the 576 e-mail address portion of the user ID only: 578 keystore.cert_validate(primary_fpr, addr) -> boolean 580 For some keystores, the presence of a certificate in the keystore 581 alone implies that the keystore asserts the validity of all user IDs 582 in the certificate retrieved. For others, the presence in the 583 keystore applies only to some part of the user ID. For example, 584 [PGP-GLOBAL-DIRECTORY] will only return user IDs that have completed 585 an e-mail validation step, so presence in that keystore implies an 586 assertion of validity of the e-mail address part of the user IDs 587 returned, but makes no claim about the "display-name" portion of any 588 returned user IDs. Note that a client retrieving a certificate from 589 such a keystore may merge the certificate with a local copy - but the 590 validity asserted by the keystore of course has no bearing on the 591 packets that the keystore did not return. 593 In a more subtle example, the retrieval of a certificate looked up 594 via WKD ([I-D.koch-openpgp-webkey-service]) or DANE ([RFC7929]) 595 should only be interpreted as a claim of validity about any user ID 596 which matches the e-mail address by which the certificate was looked 597 up, with no claims made about any "display-name" portions, or about 598 any user ID that doesn't match the queried e-mail address at all. 600 A keystore that offers some sort of validation interface may also 601 change its opinion about the validity of a given certificate or user 602 ID over time; the interface described above only allows the client to 603 ask about the keystore's current opinion, but a more complex 604 interface might be capable of describing the keystore's assertion 605 over time. See also Section 11.5. 607 An abuse-resistant keystore that clients rely on for any part of 608 their certificate validation process SHOULD offer a distinct 609 interface for making assertions about certificate and user ID 610 validity to help clients avoid some of the subtleties involved with 611 inference based on presence described above. 613 Note that the certificate validation operation as described above has 614 a boolean response. While a "true" response indicates that keystore 615 believes the user ID or e-mail address is acceptable for use with the 616 certificate referred to by the public key fingerprint, a "false" 617 response doesn't necessarily mean that the keystore actively thinks 618 that the certificate is actively bad, or must not be used for the 619 referenced identity. Rather, "false" is the default state: no 620 opinion is expressed by the keystore, and the client is left to make 621 their own inference about validity based on other factors. A 622 keystore MAY offer a more nuanced validity interface; if it does, it 623 SHOULD explicitly document the semantics of the different response 624 types so that clients can make appropriate judgment. 626 3.5. Certificate Submission 628 Different keystores have different ways to submit a certificate for 629 consideration for ingestion, including: 631 o a simple upload of a certificate via HTTP 633 o round-trip e-mail verification 635 o proof of presence in some other service 637 o vouching, or other forms of multi-party attestation 639 Because these schemes vary so widely, this document does not attempt 640 to describe the keystore certificate submission process in detail. 641 However, guidance can be found for implementations that generate, 642 manage, and submit certificates in Section 10. 644 4. Simple Mitigations 646 These steps can be taken by any keystore that wants to avoid 647 obviously malicious abuse. They can be implemented on receipt of any 648 new packet, and are based strictly on the structure of the packet 649 itself. 651 4.1. Decline Large Packets 653 While [RFC4880] permits OpenPGP packet sizes of arbitrary length, 654 OpenPGP certificates rarely need to be so large. An abuse-resistant 655 keystore SHOULD reject any OpenPGP packet larger than 8383 octets. 656 (This cutoff is chosen because it guarantees that the packet size can 657 be represented as a one- or two-octet [RFC4880] "New Format Packet 658 Length", but it could be reduced further) 660 This may cause problems for user attribute packets that contain large 661 images, but it's not clear that these images are concretely useful in 662 any context. Some keystores MAY extend this limit for user attribute 663 packets specifically, but SHOULD NOT allow even user attributes 664 packets larger than 65536 octets. 666 4.2. Enforce Strict User IDs 668 [RFC4880] indicates that User IDs are expected to be UTF-8 strings. 669 An abuse-resistant keystore MUST reject any user ID that is not valid 670 UTF-8. 672 Some abuse-resistant keystores MAY only accept User IDs that meet 673 even stricter conventions, such as an [RFC5322] "name-addr" or "addr- 674 spec", or a URL like "ssh://host.example.org" (see Section 12.2). 676 As simple text strings, User IDs don't need to be nearly as long as 677 any other packets. An abuse-resistant keystore SHOULD reject any 678 user ID packet larger than 1024 octets. 680 4.3. Scoped User IDs 682 Some abuse-resistant keystores may restrict themselves to publishing 683 only certificates with User IDs that match a specific pattern. For 684 example, [RFC7929] encourages publication in the DNS of only 685 certificates whose user IDs refer to e-mail addresses within the DNS 686 zone. [I-D.koch-openpgp-webkey-service] similarly aims to restrict 687 publication to certificates relevant to the specific e-mail domain. 689 4.4. Strip or Standardize Unhashed Subpackets 691 [RFC4880] signature packets contain an "unhashed" block of 692 subpackets. These subpackets are not covered by any cryptographic 693 signature, so they are ripe for abuse. 695 An abuse-resistant keystore SHOULD strip out all unhashed subpackets 696 but the following exceptions: 698 4.4.1. Issuer Fingerprint 700 Some certifications only identify the issuer of the certification by 701 an unhashed Issuer or Issuer Fingerprint subpacket. If a 702 certification's hashed subpacket section has no Issuer Fingerprint 703 (see [I-D.ietf-openpgp-rfc4880bis]) subpacket, then an abuse- 704 resistant keystore that has cryptographically validated the 705 certification SHOULD synthesize an appropriate Issuer Fingerprint 706 subpacket and include it in the certification's unhashed subpackets. 708 4.4.2. Cross-sigs 710 Some Primary Key Binding Signatures ("cross-sigs") are distributed as 711 unhashed subpackets in a Subkey Binding Signature. A 712 cryptographically-validating abuse-resistant keystore SHOULD be 713 willing to redistribute a valid cross-sig as an unhashed subpacket. 715 The redistributed unhashed cross-sig itself should be stripped of all 716 unhashed subpackets. 718 4.4.3. First-party Attestations 720 Some third-party certifications are attested to by the certificate 721 primary key itself in an unhashed subpacket, as described in 722 Section 8.3. A cryptographically-validating abuse-resistant keystore 723 SHOULD be willing to redistribute a valid first-party attestation as 724 an unhashed subpacket. 726 The redistributed first-party attestation itself should be stripped 727 of all unhashed subpackets. 729 4.5. Decline User Attributes 731 Due to size concerns, some abuse-resistant keystores MAY choose to 732 ignore user attribute packets entirely, as well as any certifications 733 that cover them. 735 4.6. Decline Non-exportable Certifications 737 An abuse-resistant keystore MUST NOT accept any certification that 738 has the "Exportable Certification" subpacket present and set to 0. 739 While most keystore clients will not upload these "local" 740 certifications anyway, a reasonable public keystore that wants to 741 minimize data has no business storing or distributing these 742 certifications. 744 4.7. Decline Data From the Future 746 Many OpenPGP packets have time-of-creation timestamps in them. An 747 abuse-resistant keystore with a functional real-time clock MAY decide 748 to only accept packets whose time-of-creation is in the past. 750 Note that some OpenPGP implementations may pre-generate OpenPGP 751 material intended for use only in some future window (e.g. "Here is 752 the certificate we plan to use to sign our software next year; do not 753 accept signatures from it until then."), and may use modified time- 754 of-creation timestamps to try to achieve that purpose. This material 755 would not be distributable ahead of time by an abuse-resistant 756 keystore that adopts this mitigation. 758 4.8. Accept Only Profiled Certifications 760 An aggressively abuse-resistant keystore MAY decide to only accept 761 certifications that meet a specific profile. For example, it MAY 762 reject certifications with unknown subpacket types, unknown 763 notations, or certain combinations of subpackets. This can help to 764 minimize the amount of room for garbage data uploads. 766 Any abuse-resistant keystore that adopts such a strict posture should 767 clearly document what its expected certificate profile is, and should 768 have a plan for how to extend the profile if new types of 769 certification appear that it wants to be able to distribute. 771 Note that if the profile is ever restricted (rather than extended), 772 and the restriction is applied to the material already present, such 773 a keystore is no longer append-only (see Section 7). 775 4.9. Accept Only Certificates Issued by Designated Authorities 777 An abuse-resistant keystore capable of cryptographic validation MAY 778 retain a list of designated authorities, typically in the form of a 779 set of known public keys. Upon receipt of a new OpenPGP certificate, 780 the keystore can decide whether to accept or decline each user ID of 781 the certificate based whether that user ID has a certification that 782 was issued by one or more of the designated authorities. 784 If no user IDs are certified by designated authority, such a keystore 785 SHOULD decline the certificate and its primary key entirely. Such a 786 keystore SHOULD decline to retain or propagate all certifications 787 associated with each accepted user ID except for first-party 788 certifications and certifications by the designated authorities. 790 The operator of such a keystore SHOULD have a clear policy about its 791 set of designated authorities. 793 Given the ambiguities about expiration and revocation, such a 794 keyserver SHOULD ignore expiration and revocation of authority 795 certifications, and simply accept and retain as long as the 796 cryptographic signature is valid. 798 Note that if any key is removed from the set of designated 799 authorities, and that change is applied to the existing keystore, 800 such a keystore may no longer be append-only (see Section 7). 802 4.10. Decline Packets by Blocklist 804 The maintainer of the keystore may keep a specific list of "known- 805 bad" material, and decline to accept or redistribute items matching 806 that blocklist. The material so identified could be anything, but 807 most usefully, specific public keys or User IDs could be blocked. 809 Note that if a blocklist grows to include an element already present 810 in the keystore, it will no longer be append-only (see Section 7). 812 Some keystores may choose to apply a blocklist only at retrieval time 813 and not apply it at ingestion time. This allows the keystore to be 814 append-only, and permits synchronization between keystores that don't 815 share a blocklist, and somewhat reduces the attacker's incentive for 816 flooding the keystore (see Section 5 for more discussion). 818 Note that development and maintenance of a blocklist is not without 819 its own potentials for abuse. For one thing, the blocklist may 820 itself grow without bound. Additionally, a blocklist may be socially 821 or politically contentious as it may describe data that is toxic 822 (Section 2.5) in one community or jurisdiction but not another. 823 There needs to be a clear policy about how it is managed, whether by 824 delegation to specific decision-makers, or explicit tests. 825 Furthermore, the existence of even a well-intentioned blocklist may 826 be an "attractive nuisance," drawing the interest of would-be censors 827 or other attacker interested in controlling the ecosystem reliant on 828 the keystore in question. 830 5. Retrieval-time Mitigations 832 Most of the abuse mitigations described in this document are 833 described as being applied at certificate ingestion time. It's also 834 possible to apply the same mitigations when a certificate is 835 retrieved from the keystore (that is, during certificate lookup, 836 refresh, or discovery). Applying an abuse mitigation at retrieval 837 time may help a client defend against a user ID flooding 838 (Section 2.2), certificate flooding (Section 2.1), or fingerprint 839 flooding (Section 2.3) attack. It may also help a keystore limit its 840 liability for redistributing toxic data (Section 2.5). However, only 841 mitigations applied at ingestion time are able to mitigate keystore 842 flooding attacks (Section 2.4). 844 Some mitigations (like the non-append-only mitigations described in 845 Section 7) may be applied as filters at retrieval time, while still 846 allowing access to the (potentially much larger) unfiltered dataset 847 associated given certificate or user ID via a distinct interface. 849 The rest of this section documents specific mitigations that are only 850 relevant at retrieval time (certificate discovery, lookup, or 851 refresh). 853 5.1. Redacting User IDs 855 Some abuse-resistant keystores may accept and store user IDs but 856 decline to redistribute some or all of them, while still distributing 857 the certifications that cover those redacted user IDs. This draft 858 refers to such a keystore as a "user ID redacting" keystore. 860 The certificates distributed by such a keystore are technically 861 invalid [RFC4880] "transferable public keys", because they lack a 862 user ID packet, and the distributed certifications cannot be 863 cryptographically validated independently. However, an OpenPGP 864 implementation that already knows the user IDs associated with a 865 given primary key will be capable of associating each certification 866 with the correct user ID by trial signature verification. 868 5.1.1. Certificate Refresh with Redacted User IDs 870 A user ID redacting keystore is useful for certificate refresh by a 871 client that already knows the user ID it expects to see associated 872 with the certificate. For example, a client that knows a given 873 certificate currently has two specific user IDs could access the 874 keystore to learn that one of the user IDs has been revoked, without 875 any other client learning the user IDs directly from the keystore. 877 5.1.2. Certificate Discovery with Redacted User IDs 879 A user ID redacting keystore is somewhat less useful for clients 880 doing certificate discovery. Consider the circumstance of receiving 881 a signed e-mail without access to the signing certificate. If the 882 verifier retrieves the certificate from a user ID redacting keystore 883 by via the Issuer Fingerprint from the signature, and the signature 884 validates, the received certificate might not be a valid 885 "transferable public key" unless the client can synthesize the proper 886 user ID. 888 A reasonable client that wants to validate a certification in the 889 user ID redacted certificate SHOULD try to synthesize possible user 890 IDs based on the value of the [RFC5322] From: header in the message: 892 o Decode any [RFC2047] encodings present in the raw header value, 893 converting into UTF-8 [UNICODE-NORMALIZATION] form C (NFC), 894 trimming all whitespace from the beginning and the end of the 895 string. 897 o The resulting string should be an [RFC5322] "name-addr" or "addr- 898 spec". 900 o If it is a "name-addr", convert the UTF-8 string into an OpenPGP 901 user ID and check whether the certification validates, terminating 902 on success. 904 * If the test fails, extract the "addr-spec" from the "name-addr" 905 and continue. 907 o Canonicalize the "addr-spec" according to Section 12.3, and check 908 whether the certification validates, terminating on success. 910 o If it doesn't validate wrap the canonicalized "addr-spec" in 911 angle-brackets ("<" and ">") and test the resulting minimalist 912 "name-addr" against the certification, terminating on success. 914 o If all of the above fails, synthesis has failed. 916 5.1.3. Certificate Lookup with Redacted User IDs 918 It's possible (though non-intuitive) to use a user ID redacting 919 keystore for certificate lookup. Since the keystore retains (but 920 does not distribute) the user IDs, they can be used to select 921 certificates in response to a search. The OpenPGP certificates sent 922 back in response to the search will not contain the user IDs, but a 923 client that knows the full user ID they are searching for will be 924 able to verify the returned certifications. 926 Certificate lookup from a user ID redacting keystore works better for 927 certificate lookup by exact user ID match than it does for substring 928 match, because a client that retrieves a certificate via a substring 929 match may not be able to reconstruct the redacted user ID. 931 However, without some additional restrictions on which certifications 932 are redistributed (whether the user ID is redacted or not), 933 certificate lookup can be flooded (see Section 13.1). 935 5.1.4. Hinting Redacted User IDs 937 To ensure that the distributed certificate is at least structurally a 938 valid [RFC4880] transferable public key, a user ID redacting keystore 939 MAY distribute an empty user ID (an OpenPGP packet of tag 13 whose 940 contents are a zero-octet string) in place of the omitted user ID. 941 This two-octet replacement user ID packet ("\xb4\x00") is called the 942 "unstated user ID". 944 To facilitate clients that match certifications with specific user 945 IDs, a user ID redacting keystore MAY insert a non-hashed notation 946 subpacket into the certification. The notation will have a name of 947 "uidhash", with 0x80 ("human-readable") flag unset. The value of 948 such a notation MUST be 32 octets long, and contains the SHA-256 949 cryptographic digest of the UTF-8 string of the redacted user ID. 951 A certificate refresh client which receives such a certification 952 after the "unstated user ID" SHOULD compute the SHA-256 digest of all 953 user IDs it knows about on the certificate, and compare the result 954 with the contents of the "uidhash" notation to decide which user ID 955 to try to validate the certification against. 957 5.1.5. User ID Recovery by Client Brute Force 959 User ID redaction is at best an imperfect process. Even if a 960 keystore redacts a User ID, if it ships a certification over that 961 user ID, an interested client can guess user IDs until it finds one 962 that causes the signature to verify. This is even easier when the 963 space of legitimate user IDs is relatively small, such as the set of 964 commonly-used hostnames. 966 5.2. Primary-key Only Certificate Refresh 968 Abuse-resistant keystores can defend against a fingerprint flooding 969 Section 2.3 attack during certificate refresh by implementing a 970 narrowly-constrained certificate refresh interface. 972 Such a keystore MUST accept only a full fingerprint as the search 973 parameter from the certificate refresh client, and it MUST return at 974 most a single certificate whose primary key matches the requested 975 fingerprint. It MUST NOT return more than one certificate, and it 976 MUST NOT return any certificate whose primary key does not match the 977 fingerprint. In particular, it MUST NOT return certificates where 978 only the subkey fingerprint matches. 980 Note that [I-D.shaw-openpgp-hkp] does not offer the primitive 981 described in Section 3.1 exactly. In that specification, the set of 982 keys returned by a "get" operation with a "search" parameter that 983 appears to be a full fingerprint is ambiguous. Some popular 984 implementations (e.g., [SKS]) do not currently implement this 985 mitigation, because they return certificates with subkeys that match 986 the fingerprint. 988 5.3. Require Valid Cross-Sigs for Certificate Discovery 990 By definition, certificate discovery needs to be able to match 991 subkeys, not just primary keys. This means that the mitigation in 992 Section 5.2 is ineffective for a keystore that offers a certificate 993 discovery interface. 995 An abuse-resistant keystore that aims to defend its certificate 996 discovery interface from a fingerprint flooding (Section 2.3) attack 997 can follow the following procedure. 999 Such a keystore MUST accept only a full fingerprint or a 64-bit key 1000 ID as the search parameter from the certificate discovery client. It 1001 MUST only match that fingerprint against the following: 1003 o the fingerprint or key ID of a primary key associated with a valid 1004 certificate 1006 o the fingerprint or key ID of a cryptographically-valid subkey that 1007 also has a cross-sig. 1009 This defends against the fingerprint flooding attack because a 1010 certificate will only be returned by subkey if the subkey has agreed 1011 to be associated with the primary key (and vice versa). 1013 Note that this mitigation means that certificate discovery will fail 1014 if used for subkeys that lack cross-sigs. In particular, this means 1015 that a client that tries to use the certificate discovery interface 1016 to retrieve a certificate based on its encryption-capable subkey 1017 (e.g., taking the key ID from a Public Key Encrypted Session Key 1018 (PKESK) packet) will have no success. 1020 This is an acceptable loss, since the key ID in a PKESK is typically 1021 unverifiable anyway. 1023 6. Contextual Mitigations 1025 Some mitigations make the acceptance or rejection of packets 1026 contingent on data that is already in the keystore or the keystore's 1027 developing knowledge about the world. This means that, depending on 1028 the order that the keystore encounters the various material, or how 1029 it accesses or finds the material, the final set of material retained 1030 and distributed by the keystore might be different. 1032 While this isn't necessarily bad, it may be a surprising property for 1033 some users of keystores. 1035 6.1. Accept Only Cryptographically-verifiable Certifications 1037 An abuse-resistant keystore that is capable of doing cryptographic 1038 validation MAY decide to reject certifications that it cannot 1039 cryptographically validate. 1041 This may mean that the keystore rejects some packets while it is 1042 unaware of the public key of the issuer of the packet. 1044 As long as the keystore implements the verification algorithm, Any 1045 self-signature should always be cryptographically-verifiable, since 1046 the public key of the issuer is already present in the certificate 1047 under consideration. 1049 6.2. Accept Only Certificates Issued by Known Certificates 1051 This is an extension of Section 4.9, but where the set of authorities 1052 is just the set of certificates already known to the keystore. An 1053 abuse-resistant keystore that adopts this strategy is effectively 1054 only crawling the reachable graph of OpenPGP certificates from some 1055 starting core. 1057 A keystore adopting the mitigation SHOULD have a clear documentation 1058 of the core of initial certificates it starts with, as this is 1059 effectively a policy decision. 1061 This mitigation measure may fail due to a compromise of any secret 1062 key that is associated with a primary key of a certificate already 1063 present in the keystore. Such a compromise permits an attacker to 1064 flood the rest of the network. In the event that such a compromised 1065 key is identified, it might be placed on a blocklist (see 1066 Section 4.10). In particular, if a public key is added to a 1067 blocklist for a keystore implementing this mitigation, and it is 1068 removed from the keystore, then all certificates that were only 1069 "reachable" from the blocklisted certificate should also be 1070 simultaneously removed. 1072 FIXME: There are complexities associated with this strategy when 1073 certificates expire or are revoked. If expiration or revocation 1074 cause some certificates to become "unreachable", what should such a 1075 keystore do? 1077 6.3. Rate-limit Submissions by IP Address 1079 Some OpenPGP keystores accept material from the general public over 1080 the Internet. If an abuse-resistant keystore observes a flood of 1081 material submitted to the keystore from a given Internet address, it 1082 MAY choose to throttle submissions from that address. When receiving 1083 submissions over IPv6, such a keystore MAY choose to throttle entire 1084 nearby subnets, as a malicious IPv6 host is more likely to have 1085 multiple addresses. 1087 This requires that the keystore maintain state about recent 1088 submissions over time and address. It may also be problematic for 1089 users who appear to share an IP address from the vantage of the 1090 keystore, including those behind a NAT, using a VPN, or accessing the 1091 keystore via Tor. 1093 6.4. Accept Certificates Based on Exterior Process 1095 Some public keystores resist abuse by explicitly filtering OpenPGP 1096 material based on a set of external processes. For example, 1097 [DEBIAN-KEYRING] adjudicates the contents of the "Debian keyring" 1098 keystore based on organizational procedure and manual inspection. 1100 6.5. Accept Certificates by E-mail Validation 1102 Some keystores resist abuse by declining any certificate until the 1103 user IDs have been verified by e-mail. When these "e-mail 1104 validating" keystores review a new certificate that has a user ID 1105 with an e-mail address in it, they send an e-mail to the associated 1106 address with a confirmation mechanism (e.g., a high-entropy HTTPS URL 1107 link) in it. The e-mail itself MAY be encrypted to an encryption- 1108 capable key found in the proposed certificate. If the keyholder 1109 triggers the confirmation mechanism, then the keystore accepts the 1110 certificate. 1112 Some e-mail validating keystores MAY choose to distribute 1113 certifications over all user IDs for any given certificate, but will 1114 redact (see Section 5.1) those user IDs that have not been e-mail 1115 validated. 1117 [PGP-GLOBAL-DIRECTORY] describes some concerns held by a keystore 1118 operator using this approach. [MAILVELOPE-KEYSERVER] is another 1119 example. 1121 7. Non-append-only mitigations 1123 The following mitigations may cause some previously-retained packets 1124 to be dropped after the keystore receives new information, or as time 1125 passes. This is entirely reasonable for some keystores, but it may 1126 be surprising for clients of a keystore that expect the keystore to 1127 be append-only (for example, some keyserver synchronization 1128 techniques may expect this property to hold). 1130 Furthermore, keystores that drop old data (e.g., superseded 1131 certifications) may make it difficult or impossible for their users 1132 to reason about the validity of signatures that were made in the 1133 past. See Section 11.5 for more considerations. 1135 Note also that many of these mitigations depend on cryptographic 1136 validation, so they're typically contextual as well. 1138 A keystore that needs to be append-only, or which cannot perform 1139 cryptographic validation MAY omit these mitigations. Alternately, a 1140 keystore may omit these mitigations at certificate ingestion time, 1141 but apply these mitigations at retrieval time (during certificate 1142 refresh, discovery, or lookup), and offer a more verbose (non- 1143 mitigated) interface for auditors, as described in Section 5. 1145 Note that [GnuPG] anticipates some of these suggestions with its 1146 "clean" subcommand, which is documented as: 1148 Compact (by removing all signatures except the selfsig) 1149 any user ID that is no longer usable (e.g. revoked, or 1150 expired). Then, remove any signatures that are not usable 1151 by the trust calculations. Specifically, this removes 1152 any signature that does not validate, any signature that 1153 is superseded by a later signature, revoked signatures, 1154 and signatures issued by keys that are not present on the 1155 keyring. 1157 7.1. Drop Superseded Signatures 1159 An abuse-resistant keystore SHOULD drop all signature packets that 1160 are explicitly superseded. For example, there's no reason to retain 1161 or distribute a self-sig by key K over User ID U from 2017 if the 1162 keystore have a cryptographically-valid self-sig over from 1163 2019. 1165 Note that this covers both certifications and signatures over 1166 subkeys, as both of these kinds of signature packets may be 1167 superseded. 1169 Getting this right requires a nuanced understanding of subtleties in 1170 [RFC4880] related to timing and revocation. 1172 7.2. Drop Expired Signatures 1174 If a signature packet is known to only be valid in the past, there is 1175 no reason to distribute it further. An abuse-resistant keystore with 1176 access to a functional real-time clock SHOULD drop all certifications 1177 and subkey signature packets with an expiration date in the past. 1179 Note that this assumes that the keystore and its clients all have 1180 roughly-synchronized clocks. If that is not the case, then there 1181 will be many other problems! 1183 7.3. Drop Dangling User IDs, User Attributes, and Subkeys 1185 If enough signature packets are dropped, it's possible that some of 1186 the things that those signature packets cover are no longer valid. 1188 An abuse-resistant keystore which has dropped all certifications that 1189 cover a User ID SHOULD also drop the User ID packet. 1191 Note that a User ID that becomes invalid due to revocation MUST NOT 1192 be dropped, because the User ID's revocation signature itself remains 1193 valid, and needs to be distributed. 1195 A primary key with no User IDs and no subkeys and no revocations MAY 1196 itself also be removed from distribution, though note that the 1197 removal of a primary key may make it impossible to cryptographically 1198 validate other certifications held by the keystore. 1200 7.4. Drop All Other Elements of a Directly-Revoked Certificate 1202 If the primary key of a certificate is revoked via a direct key 1203 signature, an abuse-resistant keystore SHOULD drop all the rest of 1204 the associated data (user IDs, user attributes, and subkeys, and all 1205 attendant certifications and subkey signatures). This defends 1206 against an adversary who compromises a primary key and tries to flood 1207 the certificate to hide the revocation. 1209 Note that the direct key revocation signature MUST NOT be dropped. 1211 In the event that an abuse-resistant keystore is flooded with direct 1212 key revocation signatures, it should retain the hardest, earliest 1213 revocation (see also Section 12.1). 1215 In particular, if any of the direct key revocation signatures is a 1216 "hard" revocation, the abuse-resistant keystore SHOULD retain the 1217 earliest such revocation signature (by signature creation date). 1219 Otherwise, the abuse-resistant keystore SHOULD retain the earliest 1220 "soft" direct key revocation signature it has seen. 1222 If either of the above date comparisons results in a tie between two 1223 revocation signatures of the same "hardness", an abuse-resistant 1224 keystore SHOULD retain the signature that sorts earliest based on a 1225 binary string comparison of the direct key revocation signature 1226 packet itself. 1228 7.5. Implicit Expiration Date 1230 In combination with some of the dropping mitigations above, a 1231 particularly aggressive abuse-resistant keystore MAY choose an 1232 implicit expiration date for all signature packets. For example, a 1233 signature packet that claims no expiration could be treated by the 1234 keystore as expiring 3 years after issuance. This would permit the 1235 keystore to eject old packets on a rolling basis. 1237 An abuse-resistant keystore that adopts this mitigation needs a 1238 policy for handling signature packets marked with an explicit 1239 expiration that is longer than implicit maximum. The two obvious 1240 strategies are: 1242 o cap the packet's expiration to the system's implicit expiration 1243 date, or 1245 o accept the explicit expiration date. 1247 Warning: Any implementation of this idea is pretty radical, and it's 1248 not clear what it would do to an ecosystem that depends on such a 1249 keystore. It probably needs more thinking. 1251 8. Primary Key Sovereignty 1253 A keystore can defend against malicious external flooding by treating 1254 the "first party" of each certificate as "sovereign" over that 1255 certificate. This means in practice that no part of the certificate 1256 will redistributed without explicit permission from the primary key. 1257 We call a keystore that aims to respect primary key sovereignty a 1258 "sovereignty-respecting" keystore. 1260 [RFC4880] defines "Key Server Preferences" with a "No-modify" bit. 1261 That bit has never been respected by any keyserver implementation 1262 that the author is aware of. A sovereignty-respecting keystore 1263 effectively treats that bit as always set, whether it is present in 1264 any part of the certificate or not. 1266 A sovereignty-respecting abuse-resistant keystore can apply other 1267 constraints in addition to primary-key sovereignty, of course, for 1268 reasons as diverse as performance concerns, storage capacity, legal 1269 regulation, cryptographic algorithm support, or project policy. It 1270 will not redistribute anything that has not been explicitly approved 1271 by the primary key, but that does not mean it has to redistribute 1272 everything that has been explicitly approved by the primary key. 1274 The remaining subsections of Section 8 describe some sensible 1275 strategies for a sovereignty-respecting keystore. 1277 8.1. Refresh-only Keystores 1279 Some soveriegnty-respecting keystores may resist abuse by declining 1280 to accept any user IDs or certifications whatsoever. 1282 Such a keystore MUST be capable of cryptographic validation. It 1283 accepts primary key packets, cryptographically-valid direct-key 1284 signatures from a primary key over itself, subkeys and their 1285 cryptographically-validated binding signatures (and cross-sigs, where 1286 necessary). 1288 A client of a refresh-only keystore cannot possibly use the keystore 1289 for certificate lookup, because there are no user IDs to match. And 1290 it is not particularly useful for certificate discovery, because the 1291 returned certificate would have no identity information. However, 1292 such a keystore can be used for certificate refresh, as it's possible 1293 to ship revocations (which are direct key signatures), new subkeys, 1294 updates to subkey expiration, subkey revocation, and direct key 1295 signature-based certificate expiration updates. 1297 Note that many popular OpenPGP implementations do not implement 1298 direct primary key expiration mechanisms, relying instead on user ID 1299 expirations. These user ID expiration dates or other metadata 1300 associated with a self-certification will not be distributed by an 1301 refresh-only keystore. 1303 Certificates shipped by an refresh-only keystore are technically 1304 invalid [RFC4880] "transferable public keys," because they lack a 1305 user ID packet. However many OpenPGP implementations will accept 1306 such a certificate if they already know of a user ID for the 1307 certificate, because the composite certificate resulting from a merge 1308 will be a standards-compliant transferable public key. 1310 8.2. First-party-only Keystores 1312 Slightly more permissive than the refresh-only keystore described in 1313 Section 8.1 is a sovereignty-respecting keystore that also permits 1314 user IDs and their self-sigs. 1316 A first-party-only keystore only accepts and distributes 1317 cryptographically-valid first-party certifications. Given a primary 1318 key that the keystore understands, it will only attach user IDs that 1319 have a valid self-sig, and will only accept and re-distribute subkeys 1320 that are also cryptographically valid (including requiring cross-sigs 1321 for signing-capable subkeys as recommended in [RFC4880]). 1323 This effectively avoids certificate flooding attacks, because the 1324 only party who can make a certificate overly large is the holder of 1325 the secret corresponding to the primary key itself. 1327 Note that a first-party-only keystore is still problematic for those 1328 people who rely on the keystore for retrieval of third-party 1329 certifications. Section 8.3 attempts to address this lack. 1331 8.2.1. First-party-only Without User IDs 1333 It is possible to operate an first-party-only keystore that 1334 redistributes certifications (in particular, self-sigs) while 1335 declining to redistribute user IDs themselves (see Section 5.1). 1336 This defends against concerns about publishing identifiable 1337 information, while enabling full certificate refresh for those 1338 keystore clients that already know the associated user IDs for a 1339 given certificate. 1341 8.3. First-party-attested Third-party Certifications 1343 We can augment a first-party-only sovereignty-respecting keystore to 1344 allow it to distribute third-party certifications as long as the 1345 first-party has signed off on the specific third-party certification. 1347 A first-party can sign off a third-party certification by creating a 1348 signature over the third-party certification, and attaching it to the 1349 third-party certification as an unhashed subpacket. We call such a 1350 signature an "attestation", and it is created as detailed in the 1351 steps below: 1353 o The cryptographic validity of the third-party certification SHOULD 1354 be verified by the first party before creating an attestation for 1355 it. This implies that the issuer key of the third-party 1356 certification must be known by the first party at the time when 1357 the attestation is created. 1359 o The attestation MUST be an OpenPGP signature packet of type 0x50 1360 (Third-Party Confirmation signature) 1362 o The attestation MUST contain a hashed Signature Creation Time 1363 subpacket whose value is greater than or equal to the hashed 1364 Signature Creation Time subpacket of the third-party 1365 certification. 1367 o The attestation MUST be a signature over the third-party 1368 certification, with all subpackets removed (see the discussion of 1369 signature type 0x50 in section 5.2.4 of [RFC4880]). 1371 o The attestation MUST contain a hashed "Issuer Fingerprint" 1372 subpacket with the fingerprint of the primary key of the first- 1373 party certificate. 1375 o The attestation MUST contain a hashed Notation subpacket with the 1376 name "first-party-attestation", and an empty (0-octet) value. 1378 This attestation MUST be embedded in the third-party certification as 1379 an unhashed subpacket of type 32 (Embedded Signature). The simplest 1380 possible OpenPGP certificate with such an attestation looks like the 1381 following sequence of OpenPGP packets (indentation implies 1382 embedding): 1384 - A. Primary key 1385 - B. User ID 1386 - C. Self-sig (from A, binding A to B) 1387 - D. Third-party certification (from X, binding A to B) 1388 - E. (embedded unhashed in D: Attestation from A over D) 1390 A sovereignty-respecting keystore MAY check the third-party 1391 certification itself for cryptographic validity, but explicitly MAY 1392 also omit this step as long as the first-party attestation is 1393 cryptographically valid. This allows distribution of any certificate 1394 as a self-contained unit by verifying only first-party signatures. 1395 It also allows distribution of third-party certifications made by 1396 third-parties unknown to the keystore. 1398 A sovereignty-respecting keystore MUST only accept a third-party 1399 certification if it has a first-party attestation that is 1400 cryptographically valid, verifiable by the primary key of the 1401 certificate in question, and the first-party attestation meets all 1402 the constraints in the list above. 1404 The Notation "first-party-attestation" is intended to avoid potential 1405 accidental confusion with any other use of the Third-Party 1406 Confirmation signature packet type. The author does not know of any 1407 current use that collides, but there may be future uses that we do 1408 not want to foreclose. 1410 8.3.1. Client Interactions 1412 Creating such an attestation requires multiple steps by different 1413 parties, each of which is blocked by all prior steps: 1415 o The first-party creates the certificate, and transfers it to the 1416 third party. 1418 o The third-party certifies it, and transfers their certification 1419 back to the first party. 1421 o The first party attests to the third party's certification. 1423 o Finally, the first party then transfers the compound certificate 1424 to the keystore. 1426 The complexity and length of such a sequence may represent a 1427 usability obstacle to a user who needs a third-party-certified 1428 OpenPGP certificate. 1430 No current OpenPGP client can easily create the attestations 1431 described in this section. More implementation work needs to be done 1432 to make it easy (and understandable) for a user to perform this kind 1433 of attestation. 1435 8.3.2. Attestation Revocations 1437 The certificate owner (the "first party") might at some point want to 1438 revoke their attestation over a given third-party certification. For 1439 example: Alice once was friends with Bob, but now thinks that Bob is 1440 a jerk, and wants to avoid public association with him. She used to 1441 be fine with keystores redistributing his certification of her 1442 cryptographic identity, but she no longer wants anyone to do that. 1444 A sovereignty-respecting keystore that distributes third-party 1445 certifications SHOULD respect such a revocation by declining to 1446 distribute the associated third-party certification. 1448 An "attestation revocation" is an OpenPGP signature packet of 1449 signature type 0x30 ("Certification revocation signature"), with the 1450 following properties: 1452 o The attestation revocation MUST contain a hashed Signature 1453 creation Time subpacket whose value is greater than the 1454 attestation it revokes. 1456 o The attestation revocation MUST contain a hashed "Issuer 1457 Fingerprint" subpacket with the fingerprint of the primary key of 1458 the first-party certificate. 1460 o The attestation revocation MUST contain a hashed Notation 1461 subpacket with the name "first-party-attestation" and an empty 1462 (0-octet) value. This Notation MUST be marked as critical. The 1463 criticality is to avoid possible confusion with a revocation of 1464 the third-party certification itself, in the event that the third 1465 party has indicated that the first party is a designated revoker. 1467 o Like any other revocation, the attestation revocation is made over 1468 the same data that the signature it is revoking was made over. In 1469 this case, that means: the third-party certification, with all 1470 subpackets removed (see the discussion of signature type 0x50 in 1471 section 5.2.4 of [RFC4880]). 1473 o The attestation revocation SHOULD contain a hashed "Signature 1474 Target" subpacket with "public-key algorithm" that matches the 1475 public-key algorithm of the attestation. This subpacket makes it 1476 easier for clients and keystores alike to connect an attestation 1477 revocation with an already-known first-party attestation. 1479 o The attestation revocation's hashed "Signature Target" subpacket's 1480 hash algorithm SHOULD be SHA256, and its value MUST be equal to 1481 the hash over the body of the attestation with all unhashed 1482 subpackets removed. That is, the material hashed should be the 1483 octet 0x88, followed by the four-octet length, followed by the 1484 body of the attestation with the unhashed subpacket data length 1485 set to zero. 1487 o The attestation revocation SHOULD be shipped in the sequence of 1488 signature packets after the user ID (in the same location as the 1489 third-party certification itself). This is a different location 1490 than the attestation, for reasons described in Section 8.3.3. 1492 If a keystore or a keystore client expects to see many first-party 1493 attested third-party certifications for a certificate, it SHOULD keep 1494 an index of them (the "attestation index"). To make effective use of 1495 the "Signature Target" subpacket, the attestation index should be 1496 keyed on the SHA256 hash of each indexed attestation, computed the 1497 same way it is computed for the "Signature Target" subpacket. Each 1498 entry in the attestation index should refer to both the attestation 1499 and its attested third-party certification. Note that SHA256 here is 1500 not used for its cryptographic strength, but merely as an efficiency 1501 measure for indexing. 1503 8.3.3. Distribution of Attestation Revocations 1505 The structure of an OpenPGP certificate with a revoked first-party 1506 attestation of a third-party certification looks like this series of 1507 OpenPGP packets (indentation implies embedding): 1509 - A. Primary key 1510 - B. User ID 1511 - C. Self-sig (from A, binding A to B) 1512 - D. Third-party certification (from X, binding A to B) 1513 - E. (embedded unhashed in D: Attestation from A over D) 1514 - F. Attestation Revocation (from A over D, targets+revokes E) 1516 A sovereignty-respecting keystore that sees all of these packets 1517 SHOULD respect Attestation Revocation F by not redistributing D and E 1518 at all. 1520 However, if the keystore is distributing the certificate to a client 1521 that itself may care about first-party attestations (e.g. another 1522 sovereignty-respecting keystore, or just a sovereignty-respecting 1523 client), the keystore SHOULD continue to distribute F, so that the 1524 client can know that E has been revoked. 1526 This means that the redistributed certificate will consist of this 1527 series of OpenPGP packets: 1529 - A. Primary key 1530 - B. User ID 1531 - C. Self-sig (from A, binding A to B) 1532 - F. Attestation Revocation (from A over D, target+revokes E) 1534 A client or keystore that knows about D and E can verify the 1535 signature in F. It can identify E and D by looking them up in the 1536 attestation index based on the "Signature Target" subpacket in F. 1537 or, if it lacks such an index, it can scan all first-party 1538 attestations, and do trial signature verification over all third- 1539 party certifications it knows about until it finds a match. 1541 A client or keystore that doesn't know about D or E MAY ignore and 1542 discard F, since it is not cryptographically verifiable without D and 1543 E. Maintaining an attestation index makes this kind of rejection 1544 much cheaper to compute. 1546 A legacy client or keystore that doesn't understand attestations or 1547 attestation revocations at all might mistake F as an attempt at 1548 revocation of the User ID B itself, due to its signature type, its 1549 placement in the packet stream, and its issuer being A. However, 1550 such a client has three opportunities to ignore this packet and 1551 thereby avoid this confusion efficiently. In increasing order of 1552 computational effort: 1554 o it has a critical notation set that the legacy client (by 1555 definition) does not understand, and should therefore reject. 1557 o it has a Signature Target that does not match Self-sig C. 1559 o it does not cryptographically validate when computed over A and B. 1561 8.3.4. Revoking Third-party Certifications 1563 A sovereignty-respecting keystore distributes a third-party 1564 certification based on the desires of the first party, but the third- 1565 party themselves may change their mind about the certification that 1566 they issued. In particular, they may revoke a previously attested 1567 third-party certification. This causes some additional complexity. 1569 8.3.4.1. Third-party Certification Revocations Aren't Shipped with the 1570 Certificate 1572 Distributing the third-party's revocation of their certification 1573 without the approval of the first party would arguably disrespect the 1574 first-party's sovereignty over their own certificate. For example, 1575 consider an abusively large revocation, or a revocation which 1576 contains toxic data. 1578 At the same time, if the first party were to revoke their 1579 attestation, then the third-party certification itself _and_ its 1580 third-party's revocation might not be distributed. So distributing 1581 third-party certification revocations directly on the certificate 1582 they refer to doesn't seem to solve the problem for an abuse- 1583 resistant, sovereignty-respecting keystore. 1585 8.3.4.2. Third-party Certification Revocations Ship With the Issuing 1586 Certificate 1588 Instead, a sovereignty-respecting keystore MAY ship a third-party 1589 certification revocation attached to the end of the issuing 1590 certificate, as this respects the sovereignty of all parties 1591 involved. 1593 Using the same packet references as Section 8.3, this means that the 1594 certifier's own OpenPGP certificate MAY be distributed like so: 1596 - X. Primary key 1597 - G. User ID 1598 - H. Self-sig (from X, binding X to G) 1599 - I. Subkey 1600 - J. Subkey binding signature (from X, binds I to X) 1601 - K. Certification revocation signature 1602 (from X over A and B, targets+revokes D) 1604 Note that OpenPGP packet K is unusual here, and augments the 1605 traditional Transferable Public Key structure from [RFC4880]. 1607 A client that cares about third-party certifications SHOULD maintain 1608 an index of certifications based on the SHA256 digest of the 1609 certifications themselves (the "certification index"). The 1610 certification revocation packet SHOULD contain a Signature Target 1611 subpacket using SHA256 to identify the revoked certification. The 1612 client can use this Signature Target subpacket and the certification 1613 index to identify the targeted certification and to compute the data 1614 over which the revocation is made. As with the attestation index 1615 described in Section 8.3.2, this use of SHA256 is not used for 1616 cryptographic strength, but for indexing efficiency. 1618 A client that cares about third-party certifications from key X 1619 SHOULD refresh the certificate containing X from the keystore, and 1620 verify any discovered certification revocations correctly to the 1621 appropriate certificates, searching for the targeted revocation in 1622 its certification index. 1624 A legacy client that is unaware of this augmentation of the 1625 Transferable Public Key structure is likely to consider packet K as 1626 out-of-order or inapplicable (it would typically expect only a Subkey 1627 Revocation Signature packet in this position), and so will discard 1628 it. 1630 In the event that the certificate has no subkeys (packets I and J are 1631 absent), a legacy client might consider K to be an attempt to revoke 1632 Self-Sig H. However, K's Signature Target subpacket does not point 1633 to H, and the certification is not cryptographically valid over X and 1634 G, so it should be discarded/ignored safely in that case as well. 1636 9. Keystore Client Best Practices 1638 An OpenPGP client that needs to interact with an abuse-resistant 1639 keystore can take steps to minimize the extent that its interactions 1640 with a keystore can be abused by other parties via the attacks 1641 described in Section 2. This section describes steps that an abuse- 1642 resistant client can take. 1644 9.1. Use Constrained Keystores for Lookup 1646 When performing certificate lookup, an abuse-resistant client SHOULD 1647 prefer to query abuse-resistant keystores to avoid the risks 1648 described in Section 13.1. In particular, keystores that defend 1649 against User ID Flooding are significantly more reliable for 1650 certificate lookup. 1652 9.2. Normalize Addresses and User IDs for Lookup 1654 When performing lookup by e-mail address, an abuse-resistant client 1655 SHOULD consider canonicalizing the e-mail address before searching 1656 (see Section 12.3). 1658 When searching by full User ID, unless there is a strong reason to 1659 believe that a specific non-normalized form is preferable, an abuse- 1660 resistant client SHOULD normalize the entire user ID into 1661 [UNICODE-NORMALIZATION] Form C (NFC) before performing certificate 1662 lookup. 1664 9.3. Avoid Fuzzy Lookups 1666 Certificate lookup by arbitrary substring matching, or regular 1667 expression is prone to abuse. An abuse-resistant client SHOULD 1668 prefer exact-uid or exact-email match lookups where possible. 1670 In particular, an abuse-resistant client should avoid trying to offer 1671 reliable functionality that performs these sort of fuzzy lookups, and 1672 SHOULD warn the user about risks of abuse if the user triggers a 1673 codepath that unavoidably performs such a fuzzy lookup. 1675 9.4. Prefer Full Fingerprint for Discovery and Refresh 1677 Key IDs are inherently weaker and easier to spoof or collide than 1678 full fingerprints. Where possible, an abuse-resistant keystore 1679 client SHOULD use the full fingerprint when interacting with the 1680 keystore. 1682 9.5. Use Caution with Keystore-provided Validation 1684 When an abuse-resistant client relies on a keystore for certificate 1685 validation, many things can go subtly wrong if the client fails to 1686 closely track the specific semantics of the keystore's validation 1687 claims. 1689 For example, a certificate published by WKD 1690 ([I-D.koch-openpgp-webkey-service]) at 1691 "https://openpgpkey.example.org/.well-known/openpgpkey/hu/ 1692 iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=joe.doe" offers a validation claim 1693 only for the e-mail address "joe.doe@example.org". If the 1694 certificate retrieved at that address contains other user IDs, or if 1695 the user ID containing that e-mail address contains an [RFC5322] 1696 "display-name", none of that information should be considered 1697 "validated" by the fact that the certificate was retrieved via 1698 certificate lookup by WKD. 1700 When certificate validation is represented more generally by a 1701 keystore via certificate retrieval (e.g. from an e-mail validating 1702 keyserver that has no distinct certificate validation interface), the 1703 thing validated is the certificate received from the keystore, and 1704 not the result of the merge into any local copy of the certificate 1705 already possessed by the client. 1707 Consider also timing and duration of these assertions of validity, 1708 which represent a subtle tradeoff between privacy and risk as 1709 described in Section 14.4. 1711 10. Certificate Generation and Management Best Practices 1713 An OpenPGP implementation that generates or manages certificates and 1714 expects to distribute them via abuse-resistant keystores can take 1715 steps to ensure that the certificates generated are more likely to be 1716 accessible when needed. This section describes steps such an abuse- 1717 sensitive implementation can take. 1719 10.1. Canonicalized E-Mail Addresses 1721 E-mail addresses can be written in many different ways. An abuse- 1722 sensitive implementation considering attaching a user ID containing 1723 an e-mail address on a certificate SHOULD ensure that the e-mail 1724 address is structured as simply as possible. See Section 12.3 for 1725 details about e-mail address canonicalization. 1727 For example, if the e-mail domain considers the local part to be 1728 case-insensitive (as most e-mail domains do today), if a proposed 1729 user ID contains the "addr-spec": "Alice@EXAMPLE.org", the 1730 implementation SHOULD warn the user and, if possible, propose 1731 replacing the "addr-spec" part of the user ID with 1732 "alice@example.org". 1734 10.2. Normalized User IDs 1736 User IDs are arbitrary UTF-8 strings, but UTF-8 offers several ways 1737 to represent the same string. An abuse-sensitive implementation 1738 considering attaching a user ID to a certificate SHOULD normalize the 1739 string using [UNICODE-NORMALIZATION] Form C (NFC) before creating the 1740 self-sig. 1742 At the same time, the implementation MAY also warn the user if the 1743 "compatibility" normalized form (NFKC) differs from the candidate 1744 user ID and, if appropriate, offer to convert the user ID to 1745 compatibility normalized form at the user's discretion. 1747 10.3. Avoid Large User Attributes 1749 An abuse-sensitive implementation SHOULD warn the user when attaching 1750 a user attribute larger than 8383 octets, and SHOULD refuse to attach 1751 user attributes entirely larger than 65536 octets. (See Section 4.1) 1753 10.4. Provide Cross-Sigs 1755 [RFC4880] requires cross-sigs for all signing-capable subkeys, but is 1756 agnostic about the use of cross-sigs for subkeys of other 1757 capabilities. 1759 An abuse-sensitive implementation that wants a certificate to be 1760 discoverable by subkey SHOULD provide cross-sigs for any subkey 1761 capable of making a cross-sig. 1763 10.5. Provide Issuer Fingerprint Subpackets 1765 Issuer subpackets contain only 64-bit key IDs. Issuer Fingerprint 1766 subpackets contain an unambiguous designator of the issuing key, 1767 avoiding the ambiguities described in Section 11.2. Abuse-sensitive 1768 implementations SHOULD provide Issuer Fingerprint subpackets. 1770 10.6. Put Cross-Sigs and Issuer Fingerprint in Hashed Subpackets 1772 Unhashed subpackets may be stripped or mangled. Placing cross-sigs 1773 and issuer fingerprint subpackets in the hashed subpackets will 1774 ensure that they are propagated by any cryptographically-validating 1775 keystore, even if that keystore fails to observe the exceptions in 1776 Section 4.4. 1778 10.7. Submit Certificates to Restricted, Lookup-Capable Keystores 1780 If an abuse-sensitive implementation wants other peers to be able to 1781 to retrieve the managed certificate by certificate lookup (that is, 1782 by searching based on user ID or e-mail address), it needs to be 1783 aware that submission to an unrestricted keystore is not reliable 1784 (see Section 13.1 for more details). 1786 Consequently, such an implementation SHOULD submit the managed 1787 certificate to restricted, lookup-capable keystores where possible, 1788 as those keystores are more likely to be able to offer reliable 1789 lookup. 1791 11. Side Effects and Ecosystem Impacts 1793 11.1. Designated Revoker 1795 A first-party-only keystore as described in Section 8.2 might decline 1796 to distribute revocations made by the designated revoker. This is a 1797 risk to certificate-holder who depend on this mechanism, because an 1798 important revocation might be missed by clients depending on the 1799 keystore. 1801 FIXME: adjust this document to point out where revocations from a 1802 designated revoker SHOULD be propagated, maybe even in first-party- 1803 only keystores. 1805 11.2. Key IDs vs. Fingerprints in Certificate Discovery 1807 During signature verification, a user performing certificate 1808 discovery against a keystore SHOULD prefer to use the full 1809 fingerprint as an index, rather than the 64-bit key ID. Using a 1810 64-bit key ID is more likely to run into collision attacks; and if 1811 the retrieved certificate has a matching key ID but the signature 1812 cannot be validated with it, the client is in an ambiguous state - 1813 did it retrieve the wrong certificate, or is the signature incorrect? 1814 Using the fingerprint resolves the ambiguity: the signature is 1815 incorrect, because the a fingerprint match is overwhelmingly stronger 1816 than a key ID match. 1818 Unfortunately, many OpenPGP implementations distribute signatures 1819 with only an Issuer subpacket, so a client attempting to find such a 1820 certificate MAY perform certificate discovery based on only the key 1821 ID. 1823 A keystore that offers certificate discovery MAY choose to require 1824 full fingerprint, but such a keystore will not be useful for a client 1825 attempting to verify a bare signature from an unknown party if that 1826 signature only has an Issuer subpacket (and no Issuer Fingerprint 1827 subpacket). 1829 11.3. In-band Certificates 1831 There are contexts where it is expected and acceptable that the 1832 signature appears without its certificate: for example, if the set of 1833 valid signers is already known (as in some OpenPGP-signed operating 1834 system updates), shipping the certificate alongside the signature 1835 would be pointless bloat. 1837 However, OpenPGP signatures are often found in contexts where the 1838 certificate is not yet known by the verifier. For example, many 1839 OpenPGP-signed e-mails are not accompanied by the signing 1840 certificate. 1842 In another example, the use of authentication-capable OpenPGP keys in 1843 standard SSH connections do not contain the full OpenPGP 1844 certificates, which means that the SSH clients and servers need to 1845 resort to out-of-band processes if evaluation of the OpenPGP 1846 certificates is necessary. 1848 The certificate discovery interface offered by keystores is an 1849 attempt to accommodate these situations. But in the event that a 1850 keystore is unavailable, does not know the certificate, or suffers 1851 from a flooding attack, signature validation may fail unnecessarily. 1853 In an encrypted e-mail context specifically, such a failure may also 1854 limit the client's ability to reply with an encrypted e-mail. 1856 Certificate discovery also presents a potential privacy concern for 1857 the signature verifier, as noted in Section 14.5. 1859 These problematic situations can be mitigated by shipping the 1860 certificate in-band, alongside the signature. Signers SHOULD adopt 1861 this practice where possible to reduce the dependence of the verifier 1862 on the keystores for certificate discovery. [AUTOCRYPT] is an 1863 example of e-mail recommendations that include in-band certificates. 1865 11.3.1. In-band Certificate Minimization and Validity 1867 OpenPGP certificates are potentially large. When distributing an in- 1868 band certificate alongside a signature in a context where size is a 1869 concern (e.g. bandwidth, latency, or storage costs are a factor), the 1870 distributor SHOULD reduce the size of the in-band certificate by 1871 stripping unnecessary packets. For example, the distributor may: 1873 o Strip certification and signature packets that (due to creation 1874 and expiration time) are not relevant to the time of the signature 1875 itself. This ensures that the reduced certificate is 1876 contemporaneously valid with the signature. 1878 o Strip irrelevant subkeys (and associated Subkey Binding Signature 1879 packets and cross-sigs). If the signature was issued by a 1880 signing-capable subkey, that subkey (and its binding signature and 1881 cross-sig) are clearly relevant. Other signing-capable subkeys 1882 are likely to be irrelevant. But determining which other subkeys 1883 are relevant may be context-specific. For example, in the e-mail 1884 context, an encryption-capable subkey is likely to be contextually 1885 relevant, because it enables the recipient to reply encrypted, and 1886 therefore should not be stripped. 1888 o Strip user IDs (and associated certifications) that are unlikely 1889 to be relevant to the signature in question. For example, in the 1890 e-mail context, strip any user IDs that do not match the declared 1891 sender of the message. 1893 o Strip third-party certifications that are unlikely to be relevant 1894 to the verifier. Doing this successfully requires some knowledge 1895 about what the third-parties the recipient is likely to care 1896 about. Stripping all third-party certifications is a simple means 1897 of certificate reduction. The verifier of such a certificate may 1898 need to do certificate refresh against their preferred keystore to 1899 learn about third-party certifications useful to them. 1901 11.4. Certification-capable Subkeys 1903 Much of this discussion assumes that primary keys are the only 1904 certification-capable keys in the OpenPGP ecosystem. Some proposals 1905 have been put forward that assume that subkeys can be marked as 1906 certification-capable. If subkeys are certification-capable, then 1907 much of the reasoning in this draft becomes much more complex, as 1908 subkeys themselves can be revoked by their primary key without 1909 invalidating the key material itself. That is, a subkey can be both 1910 valid (in one context) and invalid (in another context) at the same 1911 time. So questions about what data can be dropped (e.g. in 1912 Section 7) are much fuzzier, and the underlying assumptions may need 1913 to be reviewed. 1915 If some OpenPGP implementations accept certification-capable subkeys, 1916 but an abuse-resistant keystore does not accept certifications from 1917 subkeys in general, then interactions between that keystore and those 1918 implementations may be surprising. 1920 11.5. Assessing Certificates in the Past 1922 Online protocols like TLS perform signature and certificate 1923 evaluation based entirely on the present time. If a certificate that 1924 signs a TLS handshake message is invalid now, it doesn't matter 1925 whether it was valid a week ago, because the present TLS session is 1926 the context of the evaluation. 1928 But OpenPGP signatures are often evaluated at some temporal remove 1929 from when the signature was made. For example, software packages are 1930 signed at release time, but those signatures are validated at 1931 download time. A verifier that does not already know the certificate 1932 that made the signature will need to perform certificate discovery 1933 against some set of keystores to find a certificate with which to 1934 check the signature. 1936 Further complicating matters, the composable nature of an OpenPGP 1937 certificate means that the certificate associated with any particular 1938 signing key (primary key or subkey) can transform over time. So when 1939 evaluating a signature that appears to have been made by a given 1940 certificate, it may be better to try to evaluate the certificate at 1941 the time the signature was made, rather than the present time. 1943 11.5.1. Point-in-time Certificate Evaluation 1945 When evaluating a certificate at a time T in the past (for example, 1946 when trying to validate a data signature by that certificate that was 1947 created at time T), one approach is to discard all packets from the 1948 certificate if the packet has a creation time later than T. Then 1949 evaluate the resulting certificate from the remaining packets in the 1950 context of time T. 1952 However, any such evaluation MUST NOT ignore "hard" OpenPGP key 1953 revocations, regardless of their creation date. (see Section 12.1). 1955 11.5.2. Signature Verification and Non-append-only Keystores 1957 If a non-append-only keystore (Section 7) has dropped superseded 1958 (Section 7.1) or expired (Section 7.2) certifications, it's possible 1959 for the certificate composed of the remaining packets to have no 1960 valid first-party certification at the time that a given signature 1961 was made. If a user performs certificate discovery against such a 1962 keystore, the certificate it retrieves would be invalid according to 1963 [RFC4880], and consequently verification of any signature by that 1964 certificate would fail. 1966 One simple mitigation to this problem is to ship a contemporaneously- 1967 valid certificate in-band alongside the signature (see Section 11.3). 1969 If the distributor does this, then the verifier need only learn about 1970 revocations. If knowledge about revocation is needed, the verifier 1971 might perform a certificate refresh (not "certificate discovery") 1972 against any preferred keystore, including non-append-only keystores, 1973 merging what it learns into the in-band contemporary certificate. 1975 Then the signature verifier can follow the certificate evaluation 1976 process outlined in Section 11.5.1, using the merged certificate. 1978 11.6. Global Append-only Ledgers ("Blockchain") 1980 The append-only aspect of some OpenPGP keystores encourages a user of 1981 the keystore to rely on that keystore as a faithful reporter of 1982 history, and one that will not misrepresent or hide the history that 1983 they know about. An unfaithful "append-only" keystore could abuse 1984 the trust in a number of ways, including withholding revocation 1985 certificates, offering different sets of certificates to different 1986 clients doing certificate lookup, and so on. 1988 However, the most widely used append-only OpenPGP keystore, the [SKS] 1989 keyserver pool, offers no cryptographically verifiable guarantees 1990 that it will actually remain append-only. Users of the pool have 1991 traditionally relied on its distributed nature, and the presumption 1992 that coordination across a wide range of administrators would make it 1993 difficult for the pool to reliably lie or omit data. However, the 1994 endpoint most commonly used by clients to access the network is 1995 "hkps://hkps.pool.sks-keyservers.net", the default for [GnuPG]. That 1996 endpoint is increasingly consolidated, and currently consists of 1997 hosts operated by only two distinct administrators, increasing the 1998 risk of potential misuse. 2000 Offering cryptographic assurances that a keystore could remain 2001 append-only is an appealing prospect to defend against these kinds of 2002 attack. Many popular schemes for providing such assurances are known 2003 as "blockchain" technologies, or global append-only ledgers. 2005 With X.509 certificates, we have a semi-functional Certificate 2006 Transparency ([RFC6962], or "CT") ecosystem that is intended to 2007 document and preserve evidence of (mis)issuance by well-known 2008 certificate authorities (CAs), which implements a type of global 2009 append-only ledger. While the CT infrastructure remains vulnerable 2010 to certain combinations of colluding actors, it has helped to 2011 identify and sanction some failing CAs. 2013 Like other global append-only ledgers, CT itself is primarily a 2014 detection mechanism, and has no enforcement regime. If a widely-used 2015 CA were identified by certificate transparency to be untrustworthy, 2016 the rest of the ecosystem still needs to figure out how to impose 2017 sanctions or apply a remedy, which may or may not be possible. 2019 CT also has privacy implications - the certificates published in the 2020 CT logs are visible to everyone, for the lifetime of the log. 2022 For spam abatement, CT logs decline all X.509 certificates except 2023 those issued by certain CAs (those in popular browser "root stores"). 2024 This is an example of the strategy outlined in Section 4.9). 2026 Additional projects that provide some aspects of global append-only 2027 ledgers that try to address some of the concerns described here 2028 include [KEY-TRANSPARENCY] and [CONIKS], though they are not specific 2029 to OpenPGP. Both of these systems are dependent on servers operated 2030 by identity providers, however. And both offer the ability to detect 2031 a misbehaving identity provider, but no specific enforcement or 2032 recovery strategies against such an actor. 2034 It's conceivable that a keystore could piggyback on the CT logs or 2035 other blockchain/ledger mechanisms like [BITCOIN] to store 2036 irrevocable pieces of data (such as revocation certificates). 2037 Further work is needed to describe how to do this in an effective and 2038 performant way. 2040 11.7. Certificate Lookup for Identity Monitoring 2042 While certificate lookup is classically used to find a key to encrypt 2043 an outbound message to, another use case for certificate lookup is 2044 for the party in control of a particular identity to determine 2045 whether anyone else is claiming that identity. 2047 That is, a client in control of the secret key material associated 2048 with a particular certificate with user ID X might search a keystore 2049 for all certificates matching X in order to find out whether any 2050 other certificates claim it. 2052 This is an important safeguard as part of the ledger-based detection 2053 mechanisms described in Section 11.6, but may also be useful for 2054 keystores in general. 2056 However, identity monitoring against a keystore that does not defend 2057 against user ID flooding (Section 2.2) is expensive and potentially 2058 of limited value. In particular, a malicious actor with a 2059 certificate which duplicates a given User ID could flood the keystore 2060 with similar certificates, hiding whichever one is in malicious use. 2062 Since such a keystore is not considered authoritative by any 2063 reasonable client for the user ID in question, this attack forces the 2064 identity-monitoring defender to spend arbitrary resources fetching 2065 and evaluating each certificate in the flood, without knowing which 2066 certificate other clients might be evaluating. 2068 12. OpenPGP details 2070 This section collects details about common OpenPGP implementation 2071 behavior that are useful in evaluating and reasoning about OpenPGP 2072 certificates. 2074 12.1. Revocations 2076 It's useful to classify OpenPGP revocations of key material into two 2077 categories: "soft" and "hard". 2079 If the "Reason for Revocation" of an OpenPGP key is either "Key is 2080 superseded" or "Key is retired and no longer used", it is a "soft" 2081 revocation. 2083 An implementation that interprets a "soft" revocation will typically 2084 not invalidate signatures made by the associated key with a creation 2085 date that predates the date of the soft revocation. A "soft" 2086 revocation in some ways behaves like a non-overridable expiration 2087 date. 2089 All other revocations of OpenPGP keys (with any other Reason for 2090 Revocation, or with no Reason for Revocation at all) should be 2091 considered "hard". 2093 The presence of a "hard" revocation of an OpenPGP key indicates that 2094 the user should reject all signatures and certifications made by that 2095 key, regardless of the creation date of the signature. 2097 Note that some OpenPGP implementations do not distinguish between 2098 these two categories. 2100 A defensive OpenPGP implementation that does not distinguish between 2101 these two categories SHOULD treat all revocations as "hard". 2103 An implementation aware of a "soft" revocation or of key or 2104 certificate expiry at time T SHOULD accept and process a "hard" 2105 revocation even if it appears to have been issued at a time later 2106 than T. 2108 12.2. User ID Conventions 2110 [RFC4880] requires a user ID to be a UTF-8 string, but does not 2111 constrain it beyond that. In practice, a handful of conventions 2112 predominate in how User IDs are formed. 2114 The most widespread convention is a "name-addr" as defined in 2115 [RFC5322]. For example: 2117 Alice Jones 2119 But a growing number of OpenPGP certificates contain user IDs that 2120 are instead a raw [RFC5322] "addr-spec", omitting the "display-name" 2121 and the angle brackets entirely, like so: 2123 alice@example.org 2125 Some certificates have user IDs that are simply normal human names 2126 (perhaps "display-name" in [RFC5322] jargon, though not necessarily 2127 conforming to a specific ABNF). For example: 2129 Alice Jones 2131 Still other certificates identify a particular network service by 2132 scheme and hostname. For example, the administrator of an ssh host 2133 participating in the [MONKEYSPHERE] might choose a user ID for the 2134 OpenPGP representing the host like so: 2136 ssh://foo.example.net 2138 12.3. E-mail Address Canonicalization 2140 When an OpenPGP user IDs includes an "addr-spec", there still may be 2141 multiple ways of representing the addr-spec that refer to the same 2142 underlying mailbox. Having a truly canonical form of an "addr-spec" 2143 is probably impossible because of legacy deployments of mailservers 2144 that do odd things with the local part, but e-mail addresses used in 2145 an abuse-resistant ecosystem SHOULD be constrained enough to admit to 2146 some sensible form of canonicalization. 2148 12.3.1. Disallowing Non-UTF-8 Local Parts 2150 In [RFC5322], the "local-part" can be any "dot-atom". But if this is 2151 [RFC2047] decoded, it could be any arbitrary charset, not necessarily 2152 UTF-8. FIXME: Do we convert from the arbitrary charset to UTF-8? 2154 12.3.2. Domain Canonicalization 2156 FIXME: should domain name be canonicalized into punycode form? User 2157 IDs are typically user-facing, so i think the canonicalized form 2158 should be the [UNICODE-NORMALIZATION] Form C (NFC) of the domain 2159 name. Can we punt to some other draft here? 2161 12.3.3. Local Part Canonicalization 2163 FIXME: [I-D.koch-openpgp-webkey-service] recommends downcasing all 2164 ASCII characters in the left-hand side, but leaves all 2166 13. Security Considerations 2168 This document offers guidance on mitigating a range of denial-of- 2169 service attacks on public keystores, so the entire document is in 2170 effect about security considerations. 2172 Many of the mitigations described here defend individual OpenPGP 2173 certificates against flooding attacks (see Section 2.1). But only 2174 some of these mitigations defend against flooding attacks against the 2175 keystore itself (see Section 2.4), or against flooding attacks on the 2176 space of possible user IDs (see Section 2.2). Thoughtful threat 2177 modeling and monitoring of the keystore and its defenses are probably 2178 necessary to maintain the long-term health of the keystore. 2180 Section 11.1 describes a potentially scary security problem for 2181 designated revokers. 2183 TODO (more security considerations) 2185 13.1. Tension Between Unrestricted Uploads and Certificate Lookup 2187 Note that there is an inherent tension between accepting arbitrary 2188 certificate uploads and permitting effective certificate lookup. If 2189 a keystore accepts arbitrary certificate uploads for redistribution, 2190 it appears to be vulnerable to user ID flooding (Section 2.2), which 2191 makes it difficult or impossible to rely on for certificate lookup. 2193 In the broader ecosystem, it may be necessary to use gated/controlled 2194 certificate lookup mechanisms. For example, both 2195 [I-D.koch-openpgp-webkey-service] and [RFC7929] enable the 2196 administrator of a DNS domain to distribute certificates associated 2197 with e-mail addresses within that domain, while excluding other 2198 parties. As a rather different example, [I-D.mccain-keylist] offers 2199 certificate lookup on the basis of interest - a client interested in 2200 an organization can use that mechanism to learn what certificates 2201 that organization thinks are worth knowing about, associated with a 2202 range of identities regardless of the particular DNS domain. Note 2203 that [I-D.mccain-keylist] does not provide the certificates directly, 2204 but instead expects the client to be able to retrieve them by primary 2205 key fingerprint through some other keystore capable of (and 2206 responsible for) certificate refresh. 2208 14. Privacy Considerations 2210 Keystores themselves raise a host of potential privacy concerns. 2211 Additional privacy concerns are raised by traffic to and from the 2212 keystores. This section tries to outline some of the risks to the 2213 privacy of people whose certificates are stored and redistributed in 2214 public keystores, as well as risks to the privacy of people who make 2215 use of the key stores for certificate lookup, certificate discovery, 2216 or certificate refresh. 2218 14.1. Publishing Identity Information 2220 Public OpenPGP keystores often distribute names or e-mail addresses 2221 of people. Some people do not want their names or e-mail addresses 2222 distributed in a public keystore, or may change their minds about it 2223 at some point. Append-only keystores are particularly problematic in 2224 that regard. The mitigation in Section 7.4 can help such users strip 2225 their details from keys that they control. However, if an OpenPGP 2226 certificate with their details is uploaded to a keystore, but is not 2227 under their control, it's unclear what mechanisms can be used to 2228 remove the certificate that couldn't also be exploited to take down 2229 an otherwise valid certificate. 2231 Some jurisdictions may present additional legal risk for keystore 2232 operators that distribute names or e-mail addresses of non-consenting 2233 parties. 2235 Refresh-only keystores (Section 8.1) and user ID redacting keystores 2236 (Section 5.1) may reduce this particular privacy concern because they 2237 distribute no user IDs at all. 2239 14.2. Social Graph 2241 Third-party certifications effectively map out some sort of social 2242 graph. A certification asserts a statement of belief by the issuer 2243 that the real-world party identified by the user ID is in control of 2244 the subject cryptographic key material. But those connections may be 2245 potentially sensitive, and some people may not want these maps built. 2247 A first-party-only keyserver (Section 8.2) avoids this privacy 2248 concern because it distributes no third-party privacy concern. 2250 First-party attested third-party certifications described in 2251 Section 8.3 are even more relevant edges in the social graph, because 2252 their bidirectional nature suggests that both parties are aware of 2253 each other, and see some value in mutual association. 2255 14.3. Tracking Clients by Queries 2257 Even without third-party certifications, the acts of certificate 2258 lookup, certificate discovery, and certificate refresh represent a 2259 potential privacy risk, because the keystore queried gets to learn 2260 which user IDs (in the case of lookup) or which certificates (in the 2261 case of refresh or discovery) the client is interested in. In the 2262 case of certificate refresh, if a client attempts to refresh all of 2263 its known certificates from the same keystore, that set is likely to 2264 be a unique set, and therefore identifies the client. A keystore 2265 that monitors the set of queries it receives might be able to profile 2266 or track those clients who use it repeatedly. 2268 A privacy-aware client which wants to to avoid such a tracking attack 2269 MAY try to perform certificate refresh from multiple different 2270 keystores. To hide network location, a client making a network query 2271 to a keystore SHOULD use an anonymity network like [TOR]. Tools like 2272 [PARCIMONIE] are designed to facilitate this type of certificate 2273 refresh. Such a client SHOULD also decline to use protocol features 2274 that permit linkability across interactions with the same keystore, 2275 such as TLS session resumption, HTTP cookies, and so on. 2277 Keystores which permit public access and want to protect the privacy 2278 of their clients SHOULD NOT reject access from clients using [TOR] or 2279 comparable anonymity networks. Additionally, they SHOULD minimize 2280 access logs they retain. 2282 Alternately, some keystores may distribute their entire contents to 2283 any interested client, in what can be seen as the most trivial form 2284 of private information retrieval. [DEBIAN-KEYRING] is one such 2285 example; its contents are distributed as an operating system package. 2286 Clients can interrogate their local copy of such a keystore without 2287 exposing their queries to a third-party. 2289 14.4. "Live" Certificate Validation Leaks Client Activity 2291 If a client relies on a keystore's certificate validation interface, 2292 or on the presence of a certificate in a keystore as a part of its 2293 validation calculations, it's unclear how long the assertion from the 2294 keystore is or should be considered to hold. One seemingly simple 2295 approach is to simply query the keystore's validation interface each 2296 time that the client needs to validate the certificate. 2298 This "live" validation approach poses a quandary to the client in the 2299 event that the keystore is unavailable. How should in interpret the 2300 "unknown" result? In addition, live validation reveals the client's 2301 activity to the keystore with fine precision. 2303 A privacy-aware client that depends on keystores for certificate 2304 validation SHOULD NOT perform "live" certificate validation on each 2305 use it makes of the certificate. Rather, it SHOULD cache the 2306 validation information for some period of time and make use of the 2307 cached copy where possible. If such a client does a regular 2308 certificate refresh from the same keystore, it SHOULD also pre- 2309 emptively query the keystore for certificate validation at the same 2310 time. 2312 Choosing the appropriate time intervals for this kind of caching has 2313 implications for the windows of risk for the client that might use a 2314 revoked certificate. Defining an appropriate schedule to make this 2315 tradeoff is beyond the scope of this document. 2317 14.5. Certificate Discovery Leaks Client Activity 2319 The act of doing certificate discovery on unknown signatures offers a 2320 colluding keystore and remote peer a chance to track a client's 2321 consumption of a given signature. 2323 An attacker with access to keystore logs could sign a message with a 2324 unique key, and then watch the keystore activity to determine when a 2325 client consumes the signature. This is potentially a tracking or 2326 "phone-home" situation. 2328 A signer that has no interest in this particular form of tracking can 2329 mitigate this concern by shipping their certificate in-band, 2330 alongside the signature, as recommended in Section 11.3. 2332 A privacy-aware client MAY insist on in-band certificates by 2333 declining to use any certificate discovery interface at all, and 2334 treat a bare signature by an unknown certificate as an invalid 2335 signature. 2337 14.6. Certificate Refresh Leaks Client Activity 2339 The act of doing certificate refresh itself reveals some information 2340 that the client is interested in a given certificate and how it may 2341 have changed since the last time the client refreshed it, or since it 2342 was first received by the client. 2344 This is essentially the same privacy problem presented by OCSP 2345 [RFC6960] in the X.509 world. In the online world of TLS, this 2346 privacy leak is mitigated by the CertificateStatus TLS handshake 2347 extension ([RFC4366]), a.k.a. "OCSP stapling". There is no 2348 comparable solution for the store-and-forward or non-online scenarios 2349 where OpenPGP is often found. 2351 Privacy-aware clients MAY prefer to access refresh interfaces from 2352 anonymity-preserving networks like [TOR] to obscure where they are on 2353 the network, but if the certificate being refreshed is known to be 2354 used only by a single client that may not help. 2356 Privacy-aware clients MAY prefer to stage their certificate refreshes 2357 over time, but longer delays imply greater windows of vulnerability 2358 for use of an already-revoked certificate. This strategy also does 2359 not help when a previously-unknown certificate is encountered in-band 2360 (see Section 11.3), and the OpenPGP client wants to evaluate it for 2361 use in the immediate context. 2363 14.7. Distinct Keystore Interfaces Leak Client Context and Intent 2365 The distinct keystore interfaces documented in Section 3 offer subtly 2366 different semantics, and are used by a reasonable keystore client at 2367 different times. A keystore that offers distinct discovery and 2368 refresh interfaces may infer that a client visiting the refresh 2369 interface already knows about the certificate in question, or that a 2370 client visiting the discovery interface is in the process of 2371 verifying a signature from a certificate it has not seen before. 2373 HKP itself ([I-D.shaw-openpgp-hkp]) conflates these two interfaces - 2374 the same HKP query is be used to perform both discovery and refresh 2375 (though implementations like [SKS] are not at all abuse-resistant for 2376 either use), which may obscure the context and intent of the client 2377 from the keystore somewhat. 2379 A privacy-aware client that can afford the additional bandwidth and 2380 complexity MAY use the keystore's discovery interface for both 2381 refresh and discovery, since the discovery interface is a proper 2382 superset of the refresh interface. 2384 14.8. Cleartext Queries 2386 If access to the keystore happens over observable channels (e.g., 2387 cleartext connections over the Internet), then a passive network 2388 monitor could perform the same type profiling or tracking attack 2389 against clients of the keystore described in Section 14.3. Keystores 2390 which offer network access SHOULD provide encrypted transport. 2392 14.9. Traffic Analysis 2394 Even if a keystore offers encrypted transport, the size of queries 2395 and responses may provide effective identification of the specific 2396 certificates fetched during lookup, discovery, or refresh, leaving 2397 open the types of tracking attacks described in Section 14.3. 2398 Clients of keystores SHOULD pad their queries to increase the size of 2399 the anonymity set. And keystores SHOULD pad their responses. 2401 The appropriate size of padding to effectively anonymize traffic to 2402 and from keystores is likely to be mechanism- and cohort-specific. 2403 For example, padding for keystores accessed via the DNS ([RFC7929] 2404 may use different padding strategies that padding for keystores 2405 accessed over WKD ([I-D.koch-openpgp-webkey-service]), which may in 2406 turn be different from keystores accessed over HKPS 2407 ([I-D.shaw-openpgp-hkp]). A keystore which only accepts user IDs 2408 within a specific domain (e.g., Section 4.3) or which uses custom 2409 process (Section 6.4) for verification might have different padding 2410 criteria than a keystore that serves the general public. 2412 Specific padding policies or mechanisms are out of scope for this 2413 document. 2415 15. User Considerations 2417 Section 8.3.1 describes some outstanding work that needs to be done 2418 to help users understand how to produce and distribute a third-party- 2419 certified OpenPGP certificate to an abuse-resistant keystore. 2421 Additionally, some keystores present directly user-facing 2422 affordances. For example, [SKS] keyservers typically offer forms and 2423 listings that can be viewed directly in a web browser. Such a 2424 keystore SHOULD be as clear as possible about what abuse mitigations 2425 it takes (or does not take), to avoid user confusion. 2427 Keystores which do not expect to be used directly as part of a 2428 certificate validation calculation SHOULD advise clients as 2429 explicitly as possible that they offer no assertions of validity. 2431 Experience with the [SKS] keyserver network shows that many users 2432 treat the keyserver web interfaces as authoritative. That is, users 2433 act as though the keyserver network offers some type of certificate 2434 validation. Unfortunately, The developer and implementor communities 2435 explicitly disavow any authoritative role in the ecosystem, and the 2436 implementations attempt very few mitigations against abuse, 2437 permitting redistribution of even cryptographically invalid OpenPGP 2438 packets. Clearer warnings to end users might reduce this kind of 2439 misperception. Or the community could encourage the removal of 2440 frequently misinterpreted user interfaces entirely. 2442 16. IANA Considerations 2444 This document asks IANA to register two entries in the OpenPGP 2445 Notation IETF namespace, both with a reference to this document: 2447 o the "first-party-attestation" notation is defined in Section 8.3. 2449 o the "uidhash" notation is defined in Section 5.1.4. 2451 17. Document Considerations 2453 [ RFC Editor: please remove this section before publication ] 2455 This document is currently edited as markdown. Minor editorial 2456 changes can be suggested via merge requests at 2457 https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore or by 2458 e-mail to the author. Please direct all significant commentary to 2459 the public IETF OpenPGP mailing list: openpgp@ietf.org 2461 17.1. Document History 2463 substantive changes bewteen -03 and -04: 2465 o change "certificate update" to "certificate refresh" for clarity 2467 o relax first-party-attested third-party certification constraints 2468 at the suggestion of Valodim 2470 o introduce "primary key sovereignty" concept explicitly 2471 o describe how to distribute and consume attestation revocations 2473 o introduce augmentation to TPK for third-party certification 2474 revocation distribution 2476 substantive changes between -02 and -03: 2478 o new sections: 2480 * Keystore Interfaces 2482 * Keystore Client Best Practices 2484 * Certificate Generation and Management Best Practices 2486 o rename "certificate discovery" to "certificate lookup" 2488 o redefine "certificate discovery" to refer to lookup by signing 2489 (sub)key 2491 o new attack: fingerprint flooding 2493 o new retrieval-time mitigations - tighter filters on discovery and 2494 update 2496 o recommend in-band certificates where possible to avoid discovery 2497 and lookup 2499 o new privacy considerations: 2501 * distinct keystore interfaces 2503 * certificate update 2505 * certificate discovery 2507 * certificate validation 2509 o more nuance about unhashed subpacket filtering 2511 substantive changes between -01 and -02: 2513 o distinguish different forms of flooding attack 2515 o distinguish toxic data as distinct from flooding 2517 o retrieval-time mitigations 2518 o user ID redaction 2520 o references to related work (CT, keylist, CONIKS, key transparency, 2521 ledgers/"blockchain", etc) 2523 o more details about UI/UX 2525 substantive changes between -00 and -01: 2527 o split out Contextual and Non-Append-Only mitigations 2529 o documented several other mitigations, including: 2531 * Decline Data From the Future 2533 * Blocklist 2535 * Exterior Process 2537 * Designated Authorities 2539 * Known Certificates 2541 * Rate-Limiting 2543 * Scoped User IDs 2545 o documented Updates-Only Keystores 2547 o consider three different kinds of flooding 2549 o deeper discussion of privacy considerations 2551 o better documentation of Reason for Revocation 2553 o document user ID conventions 2555 18. Acknowledgements 2557 This document is the result of years of operational experience and 2558 observation, as well as conversations with many different people - 2559 users, implementors, keystore operators, etc. A non-exhaustive list 2560 of people who have contributed ideas or nuance to this document 2561 specifically includes: 2563 o Antoine Beaupre 2565 o ilf 2566 o Jamie McClelland 2568 o Jonathan McDowell 2570 o Justus Winter 2572 o Marcus Brinkmann 2574 o Micah Lee 2576 o Neal Walfield 2578 o Phil Pennock 2580 o Philihp Busby 2582 o vedaal 2584 o Vincent Breitmoser 2586 o Wiktor Kwapisiewicz 2588 19. References 2590 19.1. Normative References 2592 [I-D.ietf-openpgp-rfc4880bis] 2593 Koch, W., carlson, b., Tse, R., and D. Atkins, "OpenPGP 2594 Message Format", draft-ietf-openpgp-rfc4880bis-07 (work in 2595 progress), May 2019. 2597 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 2598 Part Three: Message Header Extensions for Non-ASCII Text", 2599 RFC 2047, DOI 10.17487/RFC2047, November 1996, 2600 . 2602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2603 Requirement Levels", BCP 14, RFC 2119, 2604 DOI 10.17487/RFC2119, March 1997, 2605 . 2607 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2608 Thayer, "OpenPGP Message Format", RFC 4880, 2609 DOI 10.17487/RFC4880, November 2007, 2610 . 2612 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2613 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2614 May 2017, . 2616 19.2. Informative References 2618 [AUTOCRYPT] 2619 Breitmoser, V., Krekel, H., and D. Gillmor, "Autocrypt - 2620 Convenient End-to-End Encryption for E-Mail", n.d., 2621 . 2623 [BITCOIN] "Bitcoin", n.d., . 2625 [CONIKS] Felten, E., Freedman, M., Melara, M., Blankstein, A., and 2626 J. Bonneau, "CONIKS Key Management System", n.d., 2627 . 2629 [DEBIAN-KEYRING] 2630 McDowell, J., "Debian Keyring", n.d., 2631 . 2633 [GnuPG] Koch, W., "Using the GNU Privacy Guard", April 2019, 2634 . 2636 [I-D.koch-openpgp-webkey-service] 2637 Koch, W., "OpenPGP Web Key Directory", draft-koch-openpgp- 2638 webkey-service-08 (work in progress), May 2019. 2640 [I-D.mccain-keylist] 2641 McCain, R., Lee, M., and N. Welch, "Distributing OpenPGP 2642 Key Fingerprints with Signed Keylist Subscriptions", 2643 draft-mccain-keylist-04 (work in progress), March 2019. 2645 [I-D.shaw-openpgp-hkp] 2646 Shaw, D., "The OpenPGP HTTP Keyserver Protocol (HKP)", 2647 draft-shaw-openpgp-hkp-00 (work in progress), March 2003. 2649 [KEY-TRANSPARENCY] 2650 Belvin, G. and R. Hurst, "Key Transparency, a transparent 2651 and secure way to look up public keys", n.d., 2652 . 2654 [MAILVELOPE-KEYSERVER] 2655 Oberndoerfer, T., "Mailvelope Keyserver", n.d., 2656 . 2658 [MONKEYSPHERE] 2659 Gillmor, D. and J. Rollins, "Monkeysphere", n.d., 2660 . 2662 [PARCIMONIE] 2663 Intrigeri, ., "Parcimonie", n.d., 2664 . 2667 [PGP-GLOBAL-DIRECTORY] 2668 Symantec Corporation, "PGP Global Directory Key 2669 Verification Policy", 2011, 2670 . 2673 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 2674 and T. Wright, "Transport Layer Security (TLS) 2675 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 2676 . 2678 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2679 DOI 10.17487/RFC5322, October 2008, 2680 . 2682 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 2683 Galperin, S., and C. Adams, "X.509 Internet Public Key 2684 Infrastructure Online Certificate Status Protocol - OCSP", 2685 RFC 6960, DOI 10.17487/RFC6960, June 2013, 2686 . 2688 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 2689 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 2690 . 2692 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 2693 (DANE) Bindings for OpenPGP", RFC 7929, 2694 DOI 10.17487/RFC7929, August 2016, 2695 . 2697 [SKS] Minsky, Y., Fiskerstrand, K., and P. Pennock, "SKS 2698 Keyserver Documentation", March 2018, 2699 . 2702 [TOR] "The Tor Project", n.d., . 2704 [UNICODE-NORMALIZATION] 2705 Whistler, K., "Unicode Normalization Forms", February 2706 2019, . 2708 Author's Address 2710 Daniel Kahn Gillmor 2711 American Civil Liberties Union 2712 125 Broad St. 2713 New York, NY 10004 2714 USA 2716 Email: dkg@fifthhorseman.net