idnits 2.17.00 (12 Aug 2021) /tmp/idnits16357/draft-dkg-openpgp-abuse-resistant-keystore-02.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 729 has weird spacing: '...ct (by remov...' == Line 732 has weird spacing: '..., this remov...' == Line 733 has weird spacing: '... any signat...' == Line 734 has weird spacing: '...revoked signa...' -- The document date (April 15, 2019) is 1132 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-openpgp-rfc4880bis-06 == Outdated reference: A later version (-14) exists of draft-koch-openpgp-webkey-service-07 == Outdated reference: A later version (-05) exists of draft-mccain-keylist-04 -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 openpgp D. Gillmor 3 Internet-Draft ACLU 4 Intended status: Informational April 15, 2019 5 Expires: October 17, 2019 7 Abuse-Resistant OpenPGP Keystores 8 draft-dkg-openpgp-abuse-resistant-keystore-02 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 can be made unusable for specific names or addresses by public 23 submission of bogus data. And finally, keystores open to public 24 submission can also face simple resource exhaustion from flooding 25 with bogus submissions, or legal or other risks from uploads of toxic 26 data. 28 This draft documents techniques that an archive of OpenPGP 29 certificates can use to mitigate the impact of these various attacks. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 17, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 69 2.1. Certificate Flooding . . . . . . . . . . . . . . . . . . 7 70 2.2. User ID Flooding . . . . . . . . . . . . . . . . . . . . 7 71 2.3. Keystore Flooding . . . . . . . . . . . . . . . . . . . . 7 72 3. Toxic Data . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 4. Simple Mitigations . . . . . . . . . . . . . . . . . . . . . 8 74 4.1. Decline Large Packets . . . . . . . . . . . . . . . . . . 8 75 4.2. Enforce Strict User IDs . . . . . . . . . . . . . . . . . 9 76 4.3. Scoped User IDs . . . . . . . . . . . . . . . . . . . . . 9 77 4.4. Strip or Standardize Unhashed Subpackets . . . . . . . . 9 78 4.5. Decline User Attributes . . . . . . . . . . . . . . . . . 10 79 4.6. Decline Non-exportable Certifications . . . . . . . . . . 10 80 4.7. Decline Data From the Future . . . . . . . . . . . . . . 10 81 4.8. Accept Only Profiled Certifications . . . . . . . . . . . 10 82 4.9. Accept Only Certificates Issued by Designated Authorities 11 83 4.10. Decline Packets by Blocklist . . . . . . . . . . . . . . 11 84 5. Retrieval-time Mitigations . . . . . . . . . . . . . . . . . 12 85 5.1. Redacting User IDs . . . . . . . . . . . . . . . . . . . 12 86 5.1.1. Certificate Update with Redacted User IDs . . . . . . 12 87 5.1.2. Certificate Discovery with Redacted User IDs . . . . 13 88 5.1.3. Hinting Redacted User IDs . . . . . . . . . . . . . . 13 89 5.1.4. User ID Recovery by Client Brute Force . . . . . . . 14 90 6. Contextual Mitigations . . . . . . . . . . . . . . . . . . . 14 91 6.1. Accept Only Cryptographically-verifiable Certifications . 14 92 6.2. Accept Only Certificates Issued by Known Certificates . . 14 93 6.3. Rate-limit Submissions by IP Address . . . . . . . . . . 15 94 6.4. Accept Certificates Based on Exterior Process . . . . . . 15 95 6.5. Accept Certificates by E-mail Validation . . . . . . . . 15 97 7. Non-append-only mitigations . . . . . . . . . . . . . . . . . 16 98 7.1. Drop Superseded Signatures . . . . . . . . . . . . . . . 16 99 7.2. Drop Expired Signatures . . . . . . . . . . . . . . . . . 17 100 7.3. Drop Dangling User IDs, User Attributes, and Subkeys . . 17 101 7.4. Drop All Other Elements of a Directly-Revoked Certificate 17 102 7.5. Implicit Expiration Date . . . . . . . . . . . . . . . . 18 103 8. Updates-only Keystores . . . . . . . . . . . . . . . . . . . 18 104 9. First-party-only Keystores . . . . . . . . . . . . . . . . . 19 105 9.1. First-party-only Without User IDs . . . . . . . . . . . . 19 106 10. First-party-attested Third-party Certifications . . . . . . . 19 107 10.1. Key Server Preferences "No-modify" . . . . . . . . . . . 21 108 10.2. Client Interactions . . . . . . . . . . . . . . . . . . 21 109 11. Side Effects and Ecosystem Impacts . . . . . . . . . . . . . 21 110 11.1. Designated Revoker . . . . . . . . . . . . . . . . . . . 21 111 11.2. Certification-capable Subkeys . . . . . . . . . . . . . 22 112 11.3. Assessing Certificates in the Past . . . . . . . . . . . 22 113 11.3.1. Point-in-time Certificate Evaluation . . . . . . . . 22 114 11.3.2. Signature Verification and Non-append-only Keystores 23 115 11.4. Global Append-only Ledgers ("Blockchain") . . . . . . . 23 116 11.5. Certificate Discovery for Identity Monitoring . . . . . 24 117 12. OpenPGP details . . . . . . . . . . . . . . . . . . . . . . . 25 118 12.1. Revocations . . . . . . . . . . . . . . . . . . . . . . 25 119 12.2. User ID Conventions . . . . . . . . . . . . . . . . . . 26 120 13. Security Considerations . . . . . . . . . . . . . . . . . . . 27 121 13.1. Tension Between Unrestricted Uploads and Certificate 122 Discovery . . . . . . . . . . . . . . . . . . . . . . . 27 123 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 124 14.1. Publishing Identity Information . . . . . . . . . . . . 28 125 14.2. Social Graph . . . . . . . . . . . . . . . . . . . . . . 28 126 14.3. Tracking Clients by Queries . . . . . . . . . . . . . . 28 127 14.4. Cleartext Queries . . . . . . . . . . . . . . . . . . . 29 128 14.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 29 129 15. User Considerations . . . . . . . . . . . . . . . . . . . . . 30 130 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 131 17. Document Considerations . . . . . . . . . . . . . . . . . . . 30 132 17.1. Document History . . . . . . . . . . . . . . . . . . . . 31 133 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 134 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 135 19.1. Normative References . . . . . . . . . . . . . . . . . . 32 136 19.2. Informative References . . . . . . . . . . . . . . . . . 33 137 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 139 1. Introduction 140 1.1. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 1.2. Terminology 150 o "OpenPGP certificate" (or just "certificate") is used 151 interchangeably with [RFC4880]'s "Transferable Public Key". The 152 term "certificate" refers unambiguously to the entire composite 153 object, unlike "key", which might also be used to refer to a 154 primary key or subkey. 156 o An "identity certification" (or just "certification") is an 157 [RFC4880] signature packet that covers OpenPGP identity 158 information - that is, any signature packet of type 0x10, 0x11, 159 0x12, or 0x13. Certifications are said to (try to) "bind" a 160 primary key to a User ID. 162 o The primary key that makes the certification is known as the 163 "issuer". The primary key over which the certification is made is 164 known as the "subject". 166 o A "first-party certification" is issued by the primary key of a 167 certificate, and binds itself to a user ID in the certificate. 168 That is, the issuer is the same as the subject. This is sometimes 169 referred to as a "self-sig". 171 o A "third-party certification" is a made over a primary key and 172 user ID by some other certification-capable primary key. That is, 173 the issuer is different than the subject. (The elusive "second- 174 party" is presumed to be the verifier who is trying to interpret 175 the certificate) 177 o A "keystore" is any collection of OpenPGP certificates. Keystores 178 typically receive mergeable updates over the course of their 179 lifetime which might add to the set of OpenPGP certificates they 180 hold, or update the certificates. 182 o "Certificate discovery" is the process whereby a user retrieves an 183 OpenPGP certificate based on user ID (see Section 12.2). A user 184 attempting to discover a certificate from a keystore will search 185 for a substring of the known user IDs, most typically an e-mail 186 address if the user ID is an [RFC5322] name-addr or addr-spec. 187 Some certificate discovery mechanisms look for an exact match on 188 the known user IDs. [I-D.koch-openpgp-webkey-service] and 189 [I-D.shaw-openpgp-hkp] both offer certificate discovery 190 mechanisms. 192 o "Certificate validation" is the process whereby a user decides 193 whether a given user ID in an OpenPGP certificate is acceptable. 194 For example, if the certificate has a user ID of "Alice 195 " and the user wants to send an e-mail to 196 "alice@example.org", the mail user agent might want to ensure that 197 the certificate is valid for this e-mail address before encrypting 198 to it. This process can take different forms, and can consider 199 many different factors, some of which are not directly contained 200 in the certificate itself. For example, certificate validation 201 might consider whether the certificate was fetched via DANE 202 ([RFC7929]) or WKD ([I-D.koch-openpgp-webkey-service]); or whether 203 it has seen e-mails from that address signed by the certificate in 204 the past; or how long it has known about certificate. 206 o "Certificate update" is the process whereby a user fetches new 207 information about a certificate, potentially merging those OpnePGP 208 packets to change the status of the certificate. Updates might 209 include adding or revoking user IDs or subkeys, updating 210 expiration dates, or even revoking the entire certificate by 211 revoking the primary key directly. A user attempting to update a 212 certificate typically queries a keystore based on the 213 certificate's fingerprint. 215 o A "keyserver" is a particular kind of keystore, typically means of 216 publicly distributing OpenPGP certificates or updates to them. 217 Examples of keyserver software include [SKS] and 218 [MAILVELOPE-KEYSERVER]. One common HTTP interface for keyservers 219 is [I-D.shaw-openpgp-hkp]. 221 o A "synchronizing keyserver" is a keyserver which gossips with 222 other peers, and typically acts as an append-only log. Such a 223 keyserver is typically useful for certificate discovery, 224 certificate updates, and revocation information. They are 225 typically _not_ useful for certificate validation, since they make 226 no assertions about whether the identities in the certificates 227 they server are accurate. As of the writing of this document, 228 [SKS] is the canonical synchronizing keyserver implementation, 229 though other implementations exist. 231 o An "e-mail validating keyserver" is a keyserver which attempts to 232 verify the identity in an OpenPGP certificate's user ID by 233 confirming access to the e-mail account, and possibly by 234 confirming access to the secret key. Some implementations permit 235 removal of a certificate by anyone who can prove access to the 236 e-mail address in question. They are useful for certificate 237 discovery based on e-mail address and certificate validation (by 238 users who trust the operator), but some may not be useful for 239 certificate update or revocation, since a certificate could be 240 simply replaced by an adversary who also has access to the e-mail 241 address in question. [MAILVELOPE-KEYSERVER] is an example of such 242 a keyserver. 244 o "Cryptographic validity" refers to mathematical evidence that a 245 signature came from the secret key associated with the public key 246 it claims to come from. Note that a certification may be 247 cryptographically valid without the signed data being true (for 248 example, a given certificate with the user ID "Alice 249 " might not belong to the person who controls 250 the e-mail address "alice@example.org" even though the self-sig is 251 cryptographically valid). In particular, cryptographic validity 252 for user ID in a certificate is typically insufficient evidence 253 for certificate validation. Also note that knowledge of the 254 public key of the issuer is necessary to determine whether any 255 given signature is cryptographically valid. Some keyservers 256 perform cryptographic validation in some contexts. Other 257 keyservers (like [SKS]) perform no cryptographic validation 258 whatsoever. 260 o OpenPGP revocations can have "Reason for Revocation" (see 261 [RFC4880]), which can be either "soft" or "hard". The set of 262 "soft" reasons is: "Key is superseded" and "Key is retired and no 263 longer used". All other reasons (and revocations that do not 264 state a reason) are "hard" revocations. See Section 12.1 for more 265 detail. 267 2. Problem Statement 269 OpenPGP keystores that handle submissions from the public are subject 270 to a range of attacks by malicious submitters. 272 This section describes four distinct attacks that public keystores 273 should consider. 275 The rest of the document describes some mitigations that can be used 276 by keystores that are concerned about these problems but want to 277 continue to offer some level of service for certificate discovery, 278 certificate update, or certificate validation. 280 2.1. Certificate Flooding 282 Many public keystores (including both the [SKS] keyserver network and 283 [MAILVELOPE-KEYSERVER]) allow anyone to attach arbitrary data (in the 284 form of third-party certifications) to any certificate, bloating that 285 certificate to the point of being impossible to effectively retrieve. 286 For example, some OpenPGP implementations simply refuse to process 287 certificates larger than a certain size. 289 This kind of Denial-of-Service attack makes it possible to make 290 someone else's certificate unretrievable from the keystore, 291 preventing certificate discovery. It also makes it possible to swamp 292 a certificate that has been revoked, preventing certificate update, 293 potentially leaving the client of the keystore with the compromised 294 certificate in an unrevoked state locally. 296 Additionally, even without malice, OpenPGP certificates can 297 potentially grow without bound. 299 2.2. User ID Flooding 301 Public keystores that are used for certificate discovery may also be 302 vulnerable to attacks that flood the space of known user IDs. In 303 particular, if the keystore accepts arbitrary certificates from the 304 public and does no verification of the user IDs, then any client 305 searching for a given user ID may need to review and process an 306 effectively unbounded set of maliciously-submitted certificates to 307 find the non-malicious certificates they are looking for. 309 For example, if an attacker knows that a given system consults a 310 keystore looking for certificates which match the e-mail address 311 "alice@example.org", the attacker may upload hundreds or thousands of 312 certificates containing user IDs that match that address. Even if 313 those certificates would not be accepted by a client (e.g., because 314 they were not certified by a known-good authority), the client 315 typically still has to wade through all of them in order to find the 316 non-malicious certificates. 318 If the keystore does not offer a discovery interface at all (that is, 319 if clients cannot search it by user ID), then user ID flooding is of 320 less consequence. 322 2.3. Keystore Flooding 324 A public keystore that accepts arbitrary OpenPGP material and is 325 append-only is at risk of being overwhelmed by sheer quantity of 326 malicious uploaded packets. This is a risk even if the user ID space 327 is not being deliberately flooded, and if individual certificates are 328 protected from flooding by any of the mechanisms described later in 329 this document. 331 The keystore itself can become difficult to operate if the total 332 quantity of data is too large, and if it is a synchronizing 333 keyserver, then the quantities of data may impose unsustainable 334 bandwidth costs on the operator as well. 336 Effectively mitigating against keystore flooding requires either 337 abandoning the append-only property that some keystores prefer, or 338 imposing very strict controls on initial ingestion. 340 3. Toxic Data 342 Like any large public dataset, it's possible that a keystore ends up 343 hosting some content that is legally actionable in some 344 jurisdictions, including libel, child pornography, material under 345 copyright or other "intellectual property" controls, blasphemy, hate 346 speech, etc. 348 A public keystore that accepts and redistributes arbitrary content 349 may face risk due to uploads of toxic data. 351 4. Simple Mitigations 353 These steps can be taken by any keystore that wants to avoid 354 obviously malicious abuse. They can be implemented on receipt of any 355 new packet, and are based strictly on the structure of the packet 356 itself. 358 4.1. Decline Large Packets 360 While [RFC4880] permits OpenPGP packet sizes of arbitrary length, 361 OpenPGP certificates rarely need to be so large. An abuse-resistant 362 keystore SHOULD reject any OpenPGP packet larger than 8383 octets. 363 (This cutoff is chosen because it guarantees that the packet size can 364 be represented as a one- or two-octet [RFC4880] "New Format Packet 365 Length", but it could be reduced further) 367 This may cause problems for user attribute packets that contain large 368 images, but it's not clear that these images are concretely useful in 369 any context. Some keystores MAY extend this limit for user attribute 370 packets specifically, but SHOULD NOT allow even user attributes 371 packets larger than 65536 octets. 373 4.2. Enforce Strict User IDs 375 [RFC4880] indicates that User IDs are expected to be UTF-8 strings. 376 An abuse-resistant keystore MUST reject any user ID that is not valid 377 UTF-8. 379 Some abuse-resistant keystores MAY only accept User IDs that meet 380 even stricter conventions, such as an [RFC5322] name-addr or addr- 381 spec, or a URL like "ssh://host.example.org". 383 As simple text strings, User IDs don't need to be nearly as long as 384 any other packets. An abuse-resistant keystore SHOULD reject any 385 user ID packet larger than 1024 octets. 387 4.3. Scoped User IDs 389 Some abuse-resistant keystores may restrict themselves to publishing 390 only certificates with User IDs that match a specific pattern. For 391 example, [RFC7929] encourages publication in the DNS of only 392 certificates whose user IDs refer to e-mail addresses within the DNS 393 zone. [I-D.koch-openpgp-webkey-service] similarly aims to restrict 394 publication to certificates relevant to the specific e-mail domain. 396 4.4. Strip or Standardize Unhashed Subpackets 398 [RFC4880] signature packets contain an "unhashed" block of 399 subpackets. These subpackets are not covered by any cryptographic 400 signature, so they are ripe for abuse. 402 An abuse-resistant keysetore SHOULD strip out all unhashed 403 subpackets. 405 Note that some certifications only identify the issuer of the 406 certification by an unhashed Issuer ID subpacket. If a 407 certification's hashed subpacket section has no Issuer ID or Issuer 408 Fingerprint (see [I-D.ietf-openpgp-rfc4880bis]) subpacket, then an 409 abuse-resistant keystore that has cryptographically validated the 410 certification SHOULD make the unhashed subpackets contain only a 411 single subpacket. That subpacket should be of type Issuer 412 Fingerprint, and should contain the fingerprint of the issuer. 414 A special exception may be made for unhashed subpackets in a third- 415 party certification that contain attestations from the certificate's 416 primary key as described in Section 10. 418 4.5. Decline User Attributes 420 Due to size concerns, some abuse-resistant keystores MAY choose to 421 ignore user attribute packets entirely, as well as any certifications 422 that cover them. 424 4.6. Decline Non-exportable Certifications 426 An abuse-resistant keystore MUST NOT accept any certification that 427 has the "Exportable Certification" subpacket present and set to 0. 428 While most keystore clients will not upload these "local" 429 certifications anyway, a reasonable public keystore that wants to 430 minimize data has no business storing or distributing these 431 certifications. 433 4.7. Decline Data From the Future 435 Many OpenPGP packets have time-of-creation timestamps in them. An 436 abuse-resistant keystore with a functional real-time clock MAY decide 437 to only accept packets whose time-of-creation is in the past. 439 Note that some OpenPGP implementations may pre-generate OpenPGP 440 material intended for use only in some future window (e.g. "Here is 441 the certificate we plan to use to sign our software next year; do not 442 accept signatures from it until then."), and may use modified time- 443 of-creation timestamps to try to achieve that purpose. This material 444 would not be distributable ahead of time by an abuse-resistant 445 keystore that adopts this mitigation. 447 4.8. Accept Only Profiled Certifications 449 An aggressively abuse-resistant keystore MAY decide to only accept 450 certifications that meet a specific profile. For example, it MAY 451 reject certifications with unknown subpacket types, unknown 452 notations, or certain combinations of subpackets. This can help to 453 minimize the amount of room for garbage data uploads. 455 Any abuse-resistant keystore that adopts such a strict posture should 456 clearly document what its expected certificate profile is, and should 457 have a plan for how to extend the profile if new types of 458 certification appear that it wants to be able to distribute. 460 Note that if the profile is ever restricted (rather than extended), 461 and the restriction is applied to the material already present, such 462 a keystore is no longer append-only (please see Section 7). 464 4.9. Accept Only Certificates Issued by Designated Authorities 466 An abuse-resistant keystore capable of cryptographic validation MAY 467 retain a list of designated authorities, typically in the form of a 468 set of known public keys. Upon receipt of a new OpenPGP certificate, 469 the keystore can decide whether to accept or decline each user ID of 470 the certificate based whether that user ID has a certification that 471 was issued by one or more of the designated authorities. 473 If no user IDs are certified by designated authority, such a keystore 474 SHOULD decline the certificate and its primary key entirely. Such a 475 keystore SHOULD decline to retain or propagate all certifications 476 associated with each accepted user ID except for first-party 477 certifications and certifications by the designated authorities. 479 The operator of such a keystore SHOULD have a clear policy about its 480 set of designated authorities. 482 Given the ambiguities about expiration and revocation, such a 483 keyserver SHOULD ignore expiration and revocation of authority 484 certifications, and simply accept and retain as long as the 485 cryptographic signature is valid. 487 Note that if any key is removed from the set of designated 488 authorities, and that change is applied to the existing keystore, 489 such a keystore may no longer be append-only (please see Section 7). 491 4.10. Decline Packets by Blocklist 493 The maintainer of the keystore may keep a specific list of "known- 494 bad" material, and decline to accept or redistribute items matching 495 that blocklist. The material so identified could be anything, but 496 most usefully, specific public keys or User IDs could be blocked. 498 Note that if a blocklist grows to include an element already present 499 in the keystore, it will no longer be append-only (please see 500 Section 7). 502 Some keystores may choose to apply a blocklist only at retrieval time 503 and not apply it at ingestion time. This allows the keystore to be 504 append-only, and permits synchronization between keystores that don't 505 share a blocklist, and somewhat reduces the attacker's incentive for 506 flooding the keystore (see Section 5 for more discussion). 508 Note that development and maintenance of a blocklist is not without 509 its own potentials for abuse. For one thing, the blocklist may 510 itself grow without bound. Additionally, a blocklist may be socially 511 or politically contentious as it may describe data that is toxic 512 (Section 3) in one community or jurisdiction but not another. There 513 needs to be a clear policy about how it is managed, whether by 514 delegation to specific decision-makers, or explicit tests. 515 Furthermore, the existence of even a well-intentioned blocklist may 516 be an "attractive nuisance," drawing the interest of would-be censors 517 or other attacker interested in controlling the ecosystem reliant on 518 the keystore in question. 520 5. Retrieval-time Mitigations 522 Most of the abuse mitigations described in this document are 523 described as being applied at certificate ingestion time. It's also 524 possible to apply the same mitigations when a certificate is 525 retrieved from the keystore (that is, during certificate update or 526 certificate discovery). Applying an abuse mitigation at retrieval 527 time may help a client defend against a user ID flooding 528 (Section 2.2) or certificate flooding (Section 2.1) attack. However, 529 only mitigations applied at ingestion time are able to mitigate 530 keystore flooding attacks (Section 2.3). 532 Some mitigations (like the non-append-only mitigations described in 533 Section 7) may be applied as filters at retrieval time, while still 534 allowing access to the (potentially much larger) unfiltered dataset 535 associated given certificate or user ID via a distinct interface. 537 The rest of this section documents a specific mitigation that is 538 applied only at retrieval time. 540 5.1. Redacting User IDs 542 Some abuse-resistant keystores may accept and store user IDs but 543 decline to redistribute some or all of them, while still distributing 544 the certifications that cover those redacted user IDs. This draft 545 refers to such a keystore as a "user ID redacting" keystore. 547 The certificates distributed by such a keystore are technically 548 invalid [RFC4880] "transferable public keys", because they lack a 549 user ID packet, and the distributed certifications cannot be 550 cryptographically validated independently. However, an OpenPGP 551 implementation that already knows the user IDs associated with a 552 given primary key will be capable of associating each certification 553 with the correct user ID by trial signature verification. 555 5.1.1. Certificate Update with Redacted User IDs 557 A user ID redacting keystore is useful for certificate update by a 558 client that already knows the user ID it expects to see associated 559 with the certificate. For example, a client that knows a given 560 certificate currently has two specific user IDs could access the 561 keystore to learn that one of the user IDs has been revoked, without 562 any other client learning the user IDs directly from the keystore. 564 5.1.2. Certificate Discovery with Redacted User IDs 566 It's possible (though non-intuitive) to use a user ID redacting 567 keystore for certificate discovery. Since the keystore retains (but 568 does not distribute) the user IDs, they can be used to select 569 certificates in response to a search. The OpenPGP certificates sent 570 back in response to the search will not contain the user IDs, but a 571 client that knows the full user ID they are searching for will be 572 able to verify the returned certifications. 574 Certificate discovery from a user ID redacting keystore works better 575 for certificate discovery by exact user ID match than it does for 576 substring match, because a client that discovers a substring match 577 may not be able to reconstruct the redacted user ID. 579 However, without some additional restrictions on which certifications 580 are redistributed (whether the user ID is redacted or not), 581 certificate discovery can be flooded (see Section 13.1). 583 5.1.3. Hinting Redacted User IDs 585 To ensure that the distributed certificate is at least structurally a 586 valid [RFC4880] transferable public key, a user ID redacting keystore 587 MAY distribute an empty user ID (an OpenPGP packet of tag 13 whose 588 contents are a zero-octet string) in place of the omitted user ID. 589 This two-octet replacement user ID packet ("\xb4\x00") is called the 590 "unstated user ID". 592 To facilitate clients that match certifications with specific user 593 IDs, a user ID redacting keystore MAY insert a non-hashed notation 594 subpacket into the certification. The notation will have a name of 595 "uidhash", with 0x80 ("human-readable") flag unset. The value of 596 such a notation MUST be 32 octets long, and contains the SHA-256 597 cryptographic digest of the UTF-8 string of the redacted user ID. 599 A certificate update client which receives such a certification after 600 the "unstated user ID" SHOULD compute the SHA-256 digest of all user 601 IDs it knows about on the certificate, and compare the result with 602 the contents of the "uidhash" notation to decide which user ID to try 603 to validate the certification against. 605 5.1.4. User ID Recovery by Client Brute Force 607 User ID redaction is at best an imperfect process. Even if a 608 keystore redacts a User ID, if it ships a certification over that 609 user ID, an interested client can guess user IDs until it finds one 610 that causes the signature to verify. This is even easier when the 611 space of legitimate user IDs is relatively small, such as the set of 612 commonly-used hostnames 614 6. Contextual Mitigations 616 Some mitigations make the acceptance or rejection of packets 617 contingent on data that is already in the keystore or the keystore's 618 developing knowledge about the world. This means that, depending on 619 the order that the keystore encounters the various material, or how 620 it discovers the material, the final set of material retained and 621 distributed by the keystore might be different. 623 While this isn't necessarily bad, it may be a surprising property for 624 some users of keystores. 626 6.1. Accept Only Cryptographically-verifiable Certifications 628 An abuse-resistant keystore that is capable of doing cryptographic 629 validation MAY decide to reject certifications that it cannot 630 cryptographically validate. 632 This may mean that the keystore rejects some packets while it is 633 unaware of the public key of the issuer of the packet. 635 6.2. Accept Only Certificates Issued by Known Certificates 637 This is an extension of Section 4.9, but where the set of authorities 638 is just the set of certificates already known to the keystore. An 639 abuse-resistant keystore that adopts this strategy is effectively 640 only crawling the reachable graph of OpenPGP certificates from some 641 starting core. 643 A keystore adopting the mitigation SHOULD have a clear documentation 644 of the core of initial certificates it starts with, as this is 645 effectively a policy decision. 647 This mitigation measure may fail due to a compromise of any secret 648 key that is associated with a primary key of a certificate already 649 present in the keystore. Such a compromise permits an attacker to 650 flood the rest of the network. In the event that such a compromised 651 key is identified, it might be placed on a blocklist (see 652 Section 4.10). In particular, if a public key is added to a 653 blocklist for a keystore implementing this mitigation, and it is 654 removed from the keystore, then all certificates that were only 655 "reachable" from the blocklisted certificate should also be 656 simultaneously removed. 658 6.3. Rate-limit Submissions by IP Address 660 Some OpenPGP keystores accept material from the general public over 661 the Internet. If an abuse-resistant keystore observes a flood of 662 material submitted to the keystore from a given Internet address, it 663 MAY choose to throttle submissions from that address. When receiving 664 submissions over IPv6, such a keystore MAY choose to throttle entire 665 nearby subnets, as a malicious IPv6 host is more likely to have 666 multiple addresses. 668 This requires that the keystore maintain state about recent 669 submissions over time and address. It may also be problematic for 670 users who appear to share an IP address from the vantage of the 671 keystore, including those behind a NAT, using a VPN, or accessing the 672 keystore via Tor. 674 6.4. Accept Certificates Based on Exterior Process 676 Some public keystores resist abuse by explicitly filtering OpenPGP 677 material based on a set of external processes. For example, 678 [DEBIAN-KEYRING] adjudicates the contents of the "Debian keyring" 679 keystore based on organizational procedure and manual inspection. 681 6.5. Accept Certificates by E-mail Validation 683 Some keystores resist abuse by declining any certificate until the 684 user IDs have been verified by e-mail. When these "e-mail 685 validating" keystores review a new certificate that has a user ID 686 with an e-mail address in it, they send an e-mail to the associated 687 address with a confirmation mechanism (e.g., a high-entropy HTTPS URL 688 link) in it. In some cases, the e-mail itself is encrypted to an 689 encryption-capable key found in the proposed certificate. If the 690 keyholder triggers the confirmation mechanism, then the keystore 691 accepts the certificate. 693 Some e-mail validating keystores MAY choose to distribute 694 certifications over all user IDs for any given certificate, but will 695 redact (see Section 5.1) those user IDs that have not been e-mail 696 validated. 698 [PGP-GLOBAL-DIRECTORY] describes some concerns held by a keystore 699 operator using this approach. [MAILVELOPE-KEYSERVER] is another 700 example. 702 7. Non-append-only mitigations 704 The following mitigations may cause some previously-retained packets 705 to be dropped after the keystore receives new information, or as time 706 passes. This is entirely reasonable for some keystores, but it may 707 be surprising for any keystore that expects to be append-only (for 708 example, some keyserver synchronization techniques may expect this 709 property to hold). 711 Furthermore, keystores that drop old data (e.g., superseded 712 certifications) may make it difficult or impossible for their users 713 to reason about the validity of signatures that were made in the 714 past. See Section 11.3 for more considerations. 716 Note also that many of these mitigations depend on cryptographic 717 validation, so they're typically contextual as well. 719 A keystore that needs to be append-only, or which cannot perform 720 cryptographic validation MAY omit these mitigations. Alternately, a 721 keystore may omit these mitigations at certificate ingestion time, 722 but apply these mitigations at retrieval time (during certificate 723 update or discovery), and offer a more verbose (non-mitigated) 724 interface for auditors, as described in Section 5. 726 Note that [GnuPG] anticipates some of these suggestions with its 727 "clean" subcommand, which is documented as: 729 Compact (by removing all signatures except the selfsig) 730 any user ID that is no longer usable (e.g. revoked, or 731 expired). Then, remove any signatures that are not usable 732 by the trust calculations. Specifically, this removes 733 any signature that does not validate, any signature that 734 is superseded by a later signature, revoked signatures, 735 and signatures issued by keys that are not present on the 736 keyring. 738 7.1. Drop Superseded Signatures 740 An abuse-resistant keystore SHOULD drop all signature packets that 741 are explicitly superseded. For example, there's no reason to retain 742 or distribute a self-sig by key K over User ID U from 2017 if the 743 keystore have a cryptographically-valid self-sig over from 744 2019. 746 Note that this covers both certifications and signatures over 747 subkeys, as both of these kinds of signature packets may be 748 superseded. 750 Getting this right requires a nuanced understanding of subtleties in 751 [RFC4880] related to timing and revocation. 753 7.2. Drop Expired Signatures 755 If a signature packet is known to only be valid in the past, there is 756 no reason to distribute it further. An abuse-resistant keystore with 757 access to a functionally real-time clock SHOULD drop all 758 certifications and subkey signature packets with an expiration date 759 in the past. 761 Note that this assumes that the keystore and its clients all have 762 roughly-synchronized clocks. If that is not the case, then there 763 will be many other problems! 765 7.3. Drop Dangling User IDs, User Attributes, and Subkeys 767 If enough signature packets are dropped, it's possible that some of 768 the things that those signature packets cover are no longer valid. 770 An abuse-resistant keystore which has dropped all certifications that 771 cover a User ID SHOULD also drop the User ID packet. 773 Note that a User ID that becomes invalid due to revocation MUST NOT 774 be dropped, because the User ID's revocation signature itself remains 775 valid, and needs to be distributed. 777 A primary key with no User IDs and no subkeys and no revocations MAY 778 itself also be removed from distribution, though note that the 779 removal of a primary key may make it impossible to cryptographically 780 validate other certifications held by the keystore. 782 7.4. Drop All Other Elements of a Directly-Revoked Certificate 784 If the primary key of a certificate is revoked via a direct key 785 signature, an abuse-resistant keystore SHOULD drop all the rest of 786 the associated data (user IDs, user attributes, and subkeys, and all 787 attendant certifications and subkey signatures). This defends 788 against an adversary who compromises a primary key and tries to flood 789 the certificate to hide the revocation. 791 Note that the direct key revocation signature MUST NOT be dropped. 793 In the event that an abuse-resistant keystore is flooded with direct 794 key revocation signatures, it should retain the hardest, earliest 795 revocation (see also Section 12.1). 797 In particular, if any of the direct key revocation signatures is a 798 "hard" revocation, the abuse-resistant keystore SHOULD retain the 799 earliest such revocation signature (by signature creation date). 801 Otherwise, the abuse-resistant keystore SHOULD retain the earliest 802 "soft" direct key revocation signature it has seen. 804 If either of the above date comparisons results in a tie between two 805 revocation signatures of the same "hardness", an abuse-resistant 806 keystore SHOULD retain the signature that sorts earliest based on a 807 binary string comparison of the direct key revocation signature 808 packet itself. 810 7.5. Implicit Expiration Date 812 In combination with some of the dropping mitigations above, a 813 particularly aggressive abuse-resistant keystore MAY choose an 814 implicit expiration date for all signature packets. For example, a 815 signature packet that claims no expiration could be treated by the 816 keystore as expiring 3 years after issuance. This would permit the 817 keystore to eject old packets on a rolling basis. 819 FIXME: it's not clear what should happen with signature packets 820 marked with an explicit expiration that is longer than implicit 821 maximum. Should it be capped to the implicit date, or accepted? 823 Warning: This idea is pretty radical, and it's not clear what it 824 would do to an ecosystem that depends on such a keystore. It 825 probably needs more thinking. 827 8. Updates-only Keystores 829 In addition to the mitigations above, some keystores may resist abuse 830 by declining to accept any user IDs or certifications whatsoever. 832 Such a keystore MUST be capable of cryptographic validation. It 833 accepts primary key packets, cryptographically-valid direct-key 834 signatures from a primary key over itself, subkeys and their 835 cryptographically-validated binding signatures (and cross signatures, 836 where necessary). 838 Clients of an updates-only keystore cannot possibly use the keystore 839 for certificate discovery, because there are no user IDs to match. 840 However, they can use it for certificate update, as it's possible to 841 ship revocations (which are direct key signatures), new subkeys, 842 updates to subkey expiration, subkey revocation, and direct key 843 signature-based certificate expiration updates. 845 Note that many popular OpenPGP implementations do not implement 846 direct primary key expiration mechanisms, relying instead on user ID 847 expirations. These user ID expiration dates or other metadata 848 associated with a self-certification will not be distributed by an 849 updates-only keystore. 851 Certificates shipped by an updates-only keystore are technically 852 invalid [RFC4880] "transferable public keys," because they lack a 853 user ID packet. However many OpenPGP implementations will accept 854 such a certificate if they already know of a user ID for the 855 certificate, because the composite certificate resulting from a merge 856 will be a standards-compliant transferable public key. 858 9. First-party-only Keystores 860 Slightly more permissive than the updates-only keystore described in 861 Section 8 is a keystore that also permits user IDs and their self- 862 sigs. 864 A first-party-only keystore only accepts and distributes 865 cryptographically-valid first-party certifications. Given a primary 866 key that the keystore understands, it will only attach user IDs that 867 have a valid self-sig, and will only accept and re-distribute subkeys 868 that are also cryptographically valid (including requiring cross-sigs 869 for signing-capable subkeys as recommended in [RFC4880]). 871 This effectively solves the problem of abusive bloating attacks on 872 any certificate, because the only party who can make a certificate 873 overly large is the holder of the secret corresponding to the primary 874 key itself. 876 Note that a first-party-only keystore is still problematic for those 877 people who rely on the keystore for discovery of third-party 878 certifications. Section 10 attempts to address this lack. 880 9.1. First-party-only Without User IDs 882 It is possible to operate an updates-only keystore that also declines 883 to redistribute user IDs (Section 5.1). This defends against 884 concerns about publishing identifiable information, while enabling 885 full certificate update for those keystore clients that already know 886 the associated user IDs for a given certificate. 888 10. First-party-attested Third-party Certifications 890 We can augment a first-party-only keystore to allow it to distribute 891 third-party certifications as long as the first-party has signed off 892 on the specific third-party certification. 894 An abuse-resistant keystore SHOULD only accept a third-party 895 certification if it meets the following criteria: 897 o The third-party certification MUST be cryptographically valid. 898 Note that this means that the keystore needs to know the primary 899 key for the issuer of the third-party certification. 901 o The third-party certification MUST have an unhashed subpacket of 902 type Embedded Signature, the contents of which we'll call the 903 "attestation". This attestation is from the certificate's primary 904 key over the third-party certification itself, as detailed in the 905 steps below: 907 o The attestation MUST be an OpenPGP signature packet of type 0x50 908 (Third-Party Confirmation signature) 910 o The attestation MUST contain a hashed "Issuer Fingerprint" 911 subpacket with the fingerprint of the primary key of the 912 certificate in question. 914 o The attestation MUST NOT be marked as non-exportable. 916 o The attestation MUST contain a hashed Notation subpacket with the 917 name "ksok", and an empty (0-octet) value. 919 o The attestation MUST contain a hashed "Signature Target" subpacket 920 with "public-key algorithm" that matches the public-key algorithm 921 of the third-party certification. 923 o The attestation's hashed "Signature Target" subpacket MUST use a 924 reasonably strong hash algorithm (as of this writing, any 925 [RFC4880] hash algorithm except MD5, SHA1, or RIPEMD160), and MUST 926 have a hash value equal to the hash over the third-party 927 certification with all unhashed subpackets removed. 929 o The attestation MUST be cryptographically valid, verifiable by the 930 primary key of the certificate in question. 932 What this means is that a third-party certificate will only be 933 accepted/distributed by the keystore if: 935 o the keystore knows about both the first- and third-parties. 937 o the third-party has made the identity assertion 939 o the first-party has confirmed that they're OK with the third-party 940 certification being distributed by any keystore. 942 FIXME: it's not clear whether the "ksok" notification is necessary - 943 it's in place to avoid some accidental confusion with any other use 944 of the Third-Party Confirmation signature packet type, but the author 945 does not know of any such use that might collide. 947 10.1. Key Server Preferences "No-modify" 949 [RFC4880] defines "Key Server Preferences" with a "No-modify" bit. 950 That bit has never been respected by any keyserver implementation 951 that the author is aware of. An abuse-resistant keystore following 952 Section 10 effectively treats that bit as always set, whether it is 953 present in the certificate or not. 955 10.2. Client Interactions 957 Creating such an attestation requires multiple steps by different 958 parties, each of which is blocked by all prior steps: 960 o The first-party creates the certificate, and transfers it to the 961 third party. 963 o The third-party certifies it, and transfers their certification 964 back to the first party. 966 o The first party attests to the third party's certification. 968 o Finally, the first party then transfers the compound certificate 969 to the keystore. 971 The complexity and length of such a sequence may represent a 972 usability obstacle to a user who needs a third-party-certified 973 OpenPGP certificate. 975 No current OpenPGP client can easily create the attestions described 976 in this section. More implementation work needs to be done to make 977 it easy (and understandable) for a user to perform this kind of 978 attestation. 980 11. Side Effects and Ecosystem Impacts 982 11.1. Designated Revoker 984 A first-party-only keystore as described in Section 9 might decline 985 to distribute revocations made by the designated revoker. This is a 986 risk to certificate-holder who depend on this mechanism, because an 987 important revocation might be missed by clients depending on the 988 keystore. 990 FIXME: adjust this document to point out where revocations from a 991 designated revoker SHOULD be propagated, maybe even in first-party- 992 only keystores. 994 11.2. Certification-capable Subkeys 996 Much of this discussion assumes that primary keys are the only 997 certification-capable keys in the OpenPGP ecosystem. Some proposals 998 have been put forward that assume that subkeys can be marked as 999 certification-capable. If subkeys are certification-capable, then 1000 much of the reasoning in this draft becomes much more complex, as 1001 subkeys themselves can be revoked by their primary key without 1002 invalidating the key material itself. That is, a subkey can be both 1003 valid (in one context) and invalid (in another context) at the same 1004 time. So questions about what data can be dropped (e.g. in 1005 Section 7) are much fuzzier, and the underlying assumptions may need 1006 to be reviewed. 1008 If some OpenPGP implementations accept certification-capable subkeys, 1009 but an abuse-resistant keystore does not accept certifications from 1010 subkeys in general, then interactions between that keystore and those 1011 implementations may be surprising. 1013 11.3. Assessing Certificates in the Past 1015 Online protocols like TLS perform signature and certificate 1016 evaluation based entirely on the present time. If a certificate that 1017 signs a TLS handshake message is invalid now, it doesn't matter 1018 whether it was valid a week ago, because the present TLS session is 1019 the context of the evaluation. 1021 But OpenPGP signatures are often evaluated at some temporal remove 1022 from when the signature was made. For example, software packages are 1023 signed at release time, but those signatures are validated at 1024 download time. 1026 Further complicating matters, the composable nature of an OpenPGP 1027 certificate means that the certificate associated with any particular 1028 signing key (primary key or subkey) can transform over time. So when 1029 evaluating a signature that appears to have been made by a given 1030 certificate, it may be better to try to evaluate the certificate at 1031 the time the signature was made, rather than the present time. 1033 11.3.1. Point-in-time Certificate Evaluation 1035 When evaluating a certificate at a time T in the past (for example, 1036 when trying to validate a data signature by that certificate that was 1037 created at time T), one approach is to discard all packets from the 1038 certificate if the packet has a creation time later than T. Then 1039 evaluate the resulting certificate from the remaining packets in the 1040 context of time T. 1042 However, any such evaluation MUST NOT ignore "hard" OpenPGP key 1043 revocations, regardless of their creation date. (see Section 12.1). 1045 11.3.2. Signature Verification and Non-append-only Keystores 1047 If a non-append-only keystore (Section 7) has dropped superseded 1048 (Section 7.1) or expired (Section 7.2) certifications, it's possible 1049 for the certificate composed of the remaining packets to have no 1050 valid first-party certification at the time that a given signature 1051 was made. Such a certificate would be invalid according to 1052 [RFC4880], and consequently verification of any signature . 1054 However, there is a simple mitigation: anyone distributing a 1055 signature (e.g. a software archive) should ship the contemporary 1056 signing certificate alongside the signature. If the distributor does 1057 this, then the verifier can perform a certificate update (to learn 1058 about revocations) against any preferred keystore, including non- 1059 append-only keystores, merging what it learns into the distributed 1060 contemporary certificate. 1062 Then the signature verifier can follow the certificate evaluation 1063 process outlined in Section 11.3.1, using the merged certificate. 1065 11.4. Global Append-only Ledgers ("Blockchain") 1067 The append-only aspect of some OpenPGP keystores encourages a user of 1068 the keystore to rely on that keystore as a faithful reporter of 1069 history, and one that will not misrepresent or hide the history that 1070 they know about. An unfaithful "append-only" keystore could abuse 1071 the trust in a number of ways, including withholding revocation 1072 certificates, offering different sets of certificates to different 1073 clients doing key discovery, and so on. 1075 However, the most widely used append-only OpenPGP keystore, the [SKS] 1076 keyserver pool, offers no cryptographically verifiable guarantees 1077 that it will actually remain append-only. Users of the pool have 1078 traditionally relied on its distributed nature, and the presumption 1079 that coordination across a wide range of administrators would make it 1080 difficult for the pool to reliably lie or omit data. However, the 1081 endpoint most commonly used by clients to access the network is 1082 "hkps://hkps.pool.sks-keyservers.net", the default for [GnuPG]. That 1083 endpoint is increasingly consolidated, and currently consists of 1084 hosts operated by only two distinct administrators, increasing the 1085 risk of potential misuse. 1087 Offering cryptographic assurances that a keystore could remain 1088 append-only is an appealing prospect to defend against these kinds of 1089 attack. Many popular schemes for providing such assurances are known 1090 as "blockchain" technologies, or global append-only ledgers. 1092 With X.509 certificates, we have a semi-functional Certificate 1093 Transparency ([RFC6962], or "CT") ecosystem that is intended to 1094 document and preserve evidence of (mis)issuance by well-known 1095 certificate authorities (CAs), which implements a type of global 1096 append-only ledger. While the CT infrastructure remains vulnerable 1097 to certain combinations of colluding actors, it has helped to 1098 identify and sanction some failing CAs. 1100 Like other global append-only ledgers, CT itself is primarily a 1101 detection mechanism, and has no enforcement regime. If a widely-used 1102 CA were identified by certificate transparency to be untrustworthy, 1103 the rest of the ecosystem still needs to figure out how to impose 1104 sanctions or apply a remedy, which may or may not be possible. 1106 CT also has privacy implications - the certificates published in the 1107 CT logs are visible to everyone, for the lifetime of the log. 1109 For spam abatement, CT logs decline all X.509 certificates except 1110 those issued by certain CAs (those in popular browser "root stores"). 1111 This is an example of the strategy outlined in Section 4.9). 1113 Additional projects that provide some aspects of global append-only 1114 ledgers that try to address some of the concerns described here 1115 include [KEY-TRANSPARENCY] and [CONIKS], though they are not specific 1116 to OpenPGP. Both of these systems are dependent on servers operated 1117 by identity providers, however. And both offer the ability to detect 1118 a misbehaving identity provider, but no specific enforcement or 1119 recovery strategies against such an actor. 1121 It's conceivable that a keystore could piggyback on the CT logs or 1122 other blockchain/ledger mechanisms like [BITCOIN] to store 1123 irrevocable pieces of data (such as revocation certificates). 1124 Further work is needed to describe how to do this in an effective and 1125 performant way. 1127 11.5. Certificate Discovery for Identity Monitoring 1129 A typical use case for certificate discovery is a user looking for a 1130 certificate in order to be able to encrypt an outbound message 1131 intended for a given e-mail address, but this is not the only use 1132 case. 1134 Another use caes is when the party in control of a particular 1135 identity wants to determine whether anyone else is claiming that 1136 identity. That is, a client in control of the secret key material 1137 associated with a particular certificate with user ID X might search 1138 a keystore for all certificates matching X in order to discover 1139 whether any other certificates claim it. 1141 This is an important safeguard as part of the ledger-based detection 1142 mechanisms described in Section 11.4, but may also be useful for 1143 keystores in general. 1145 However, identity monitoring against a keystore that does not defend 1146 against user ID flooding (Section 2.2) is expensive and potentially 1147 of limited value. In particular, a malicious actor with a 1148 certificate which duplicates a given User ID could flood the keystore 1149 with similar certificates, hiding whichever one is in malicious use. 1151 Since such a keystore is not considered authoritative by any 1152 reasonable client for the user ID in question, this attack forces the 1153 identity-monitoring defender to spend arbitrary resources fetching 1154 and evaluating each certificate in the flood, without knowing which 1155 certificate other clients might be evaluating. 1157 12. OpenPGP details 1159 This section collects details about common OpenPGP implementation 1160 behavior that are useful in evaluating and reasoning about OpenPGP 1161 certificates. 1163 12.1. Revocations 1165 It's useful to classify OpenPGP revocations of key material into two 1166 categories: "soft" and "hard". 1168 If the "Reason for Revocation" of an OpenPGP key is either "Key is 1169 superseded" or "Key is retired and no longer used", it is a "soft" 1170 revocation. 1172 An implementation that interprets a "soft" revocation will typically 1173 not invalidate signatures made by the associated key with a creation 1174 date that predates the date of the soft revocation. A "soft" 1175 revocation in some ways behaves like a non-overridable expiration 1176 date. 1178 All other revocations of OpenPGP keys (with any other Reason for 1179 Revocation, or with no Reason for Revocation at all) should be 1180 considered "hard". 1182 The presence of a "hard" revocation of an OpenPGP key indicates that 1183 the user should reject all signatures and certifications made by that 1184 key, regardless of the creation date of the signature. 1186 Note that some OpenPGP implementations do not distinguish between 1187 these two categories. 1189 A defensive OpenPGP implementation that does not distinguish between 1190 these two categories SHOULD treat all revocations as "hard". 1192 An implementation aware of a "soft" revocation or of key or 1193 certificate expiry at time T SHOULD accept and process a "hard" 1194 revocation even if it appears to have been issued at a time later 1195 than T. 1197 12.2. User ID Conventions 1199 [RFC4880] requires a user ID to be a UTF-8 string, but does not 1200 constrain it beyond that. In practice, a handful of conventions 1201 predominate in how User IDs are formed. 1203 The most widespread convention is a name-addr as defined in 1204 [RFC5322]. For example: 1206 Alice Jones 1208 But a growing number of OpenPGP certificates contain user IDs that 1209 are instead a raw [RFC5322] addr-spec, omitting the display-name and 1210 the angle brackets entirely, like so: 1212 alice@example.org 1214 Some certificates have user IDs that are simply "normal" human names 1215 (perhaps display-name in [RFC5322] jargon, though not necessarily 1216 conforming to a specific ABNF). For example: 1218 Alice Jones 1220 Still other certificates identify a particular network service by 1221 scheme and hostname. For example, the administrator of an ssh host 1222 participating in the [MONKEYSPHERE] might choose a user ID for the 1223 OpenPGP representing the host like so: 1225 ssh://foo.example.net 1227 13. Security Considerations 1229 This document offers guidance on mitigating a range of denial-of- 1230 service attacks on public keystores, so the entire document is in 1231 effect about security considerations. 1233 Many of the mitigations described here defend individual OpenPGP 1234 certificates against flooding attacks (see Section 2.1). But only 1235 some of these mitigations defend against flooding attacks against the 1236 keystore itself (see Section 2.3), or against flooding attacks on the 1237 space of possible user IDs (see Section 2.2). Thoughtful threat 1238 modeling and monitoring of the keystore and its defenses are probably 1239 necessary to maintain the long-term health of the keystore. 1241 Section 11.1 describes a potentially scary security problem for 1242 designated revokers. 1244 TODO (more security considerations) 1246 13.1. Tension Between Unrestricted Uploads and Certificate Discovery 1248 Note that there is an inherent tension between accepting arbitrary 1249 certificate uploads and permitting effective certificate discovery. 1250 If a keystore accepts arbitrary certificate uploads for 1251 redistribution, it appears to be vulnerable to user ID flooding 1252 (Section 2.2), which makes it difficult or impossible to rely on for 1253 certificate discovery. 1255 In the broader ecosystem, it may be necessary to use gated/controlled 1256 certificate discovery mechanisms. For example, both 1257 [I-D.koch-openpgp-webkey-service] and [RFC7929] enable the 1258 administrator of a DNS domain to distribute certificates associated 1259 with e-mail addresses within that domain, while excluding other 1260 parties. As a rather different example, [I-D.mccain-keylist] offers 1261 certificate discovery on the basis of interest - a client interested 1262 in an organization can use that mechanism to learn what certificates 1263 that organization thinks are worth knowing about, regardless of the 1264 particular DNS domain. Note that this [I-D.mccain-keylist] does not 1265 provide the certificates directly, but instead expects the client to 1266 be able to retrieve them by certificate fingerprint through some 1267 other keystore capable of (and responsible for) certificate update. 1269 14. Privacy Considerations 1271 Keystores themselves raise a host of potential privacy concerns. 1272 Additional privacy concerns are raised by traffic to and from the 1273 keystores. This section tries to outline some of the risks to the 1274 privacy of people whose certificates are stored and redistributed in 1275 public keystores, as well as risks to the privacy of people who make 1276 use of the key stores for certificate discovery or certificate 1277 update. 1279 TODO (more privacy considerations) 1281 14.1. Publishing Identity Information 1283 Public OpenPGP keystores often distribute names or e-mail addresses 1284 of people. Some people do not want their names or e-mail addresses 1285 distributed in a public keystore, or may change their minds about it 1286 at some point. Append-only keystores are particularly problematic in 1287 that regard. The mitigation in Section 7.4 can help such users strip 1288 their details from keys that they control. However, if an OpenPGP 1289 certificate with their details is uploaded to a keystore, but is not 1290 under their control, it's unclear what mechanisms can be used to 1291 remove the certificate that couldn't also be exploited to take down 1292 an otherwise valid certificate. 1294 Some jurisdictions may present additional legal risk for keystore 1295 operators that distribute names or e-mail addresses of non-consenting 1296 parties. 1298 Updates-only keystores (Section 8) and user ID redacting keystores 1299 (Section 5.1) may reduce this particular privacy concern because they 1300 distribute no user IDs at all. 1302 14.2. Social Graph 1304 Third-party certifications effectively map out some sort of social 1305 graph. A certification asserts a statement of belief by the issuer 1306 that the real-world party identified by the user ID is in control of 1307 the subject cryptographic key material. But those connections may be 1308 potentially sensitive, and some people may not want these maps built. 1310 A first-party-only keyserver (Section 9) avoids this privacy concern 1311 because it distribues no third-party privacy concern. 1313 First-party attested third-party certifications described in 1314 Section 10 are even more relevant edges in the social graph, because 1315 their bidirectional nature suggests that both parties are aware of 1316 each other, and see some value in mutual association. 1318 14.3. Tracking Clients by Queries 1320 Even without third-party certifications, the acts of certificate 1321 discovery and certificate update represent a potential privacy risk, 1322 because the keystore queried gets to learn which user IDs (in the 1323 case of discovery) or which certificates (in the case of update) the 1324 client is interested in. In the case of certificate update, if a 1325 client attempts to update all of its known certificates from the same 1326 keystore, that set is likely to be a unique set, and therefore 1327 identifies the client. A keystore that monitors the set of queries 1328 it receives might be able to profile or track those clients who use 1329 it repeatedly. 1331 Clients which want to to avoid such a tracking attack MAY try to 1332 perform certificate update from multiple different keystores. To 1333 hide network location, a client making a network query to a keystore 1334 SHOULD use an anonymity network like [TOR]. Tools like [PARCIMONIE] 1335 are designed to facilitate this type of certificate update. 1337 Keystores which permit public access and want to protect the privacy 1338 of their clients SHOULD NOT reject access from clients using [TOR] or 1339 comparable anonymity networks. Additionally, they SHOULD minimize 1340 access logs they retain. 1342 Alternately, some keystores may distribute their entire contents to 1343 any interested client, in what can be seen as the most trivial form 1344 of private information retrieval. [DEBIAN-KEYRING] is one such 1345 example; its contents are distributed as an operating system package. 1346 Clients can interrogate their local copy of such a keystore without 1347 exposing their queries to a third-party. 1349 14.4. Cleartext Queries 1351 If access to the keystore happens over observable channels (e.g., 1352 cleartext connections over the Internet), then a passive network 1353 monitor could perform the same type profiling or tracking attack 1354 against clients of the keystore described in Section 14.3. Keystores 1355 which offer network access SHOULD provide encrypted transport. 1357 14.5. Traffic Analysis 1359 Even if a keystore offers encrypted transport, the size of queries 1360 and responses may provide effective identification of the specific 1361 certificates fetched during discovery or update, leaving open the 1362 types of tracking attacks described in Section 14.3. Clients of 1363 keystores SHOULD pad their queries to increase the size of the 1364 anonymity set. And keystores SHOULD pad their responses. 1366 The appropriate size of padding to effectively anonymize traffic to 1367 and from keystores is likely to be mechanism- and cohort-specific. 1368 For example, padding for keystores accessed via the DNS ([RFC7929] 1369 may use different padding strategies that padding for keystores 1370 accessed over WKD ([I-D.koch-openpgp-webkey-service]), which may in 1371 turn be different from keystores accessed over HKPS 1372 ([I-D.shaw-openpgp-hkp]). A keystore which only accepts user IDs 1373 within a specific domain (e.g., Section 4.3) or which uses custom 1374 process (Section 6.4) for verification might have different padding 1375 criteria than a keystore that serves the general public. 1377 Specific padding policies or mechanisms are out of scope for this 1378 document. 1380 15. User Considerations 1382 Section 10.2 describes some outstanding work that needs to be done to 1383 help users understand how to produce and distribute a third-party- 1384 certified OpenPGP certificate to an abuse-resistant keystore. 1386 Additionally, some keystores present directly user-facing 1387 affordances. For example, [SKS] keyservers typically offer forms and 1388 listings that can be viewed directly in a web browser. Such a 1389 keystore SHOULD be as clear as possible about what abuse mitigations 1390 it takes (or does not take), to avoid user confusion. 1392 Experience with the [SKS] keyserver network shows that many users 1393 treat the keyserver web interfaces as authoritative, even though the 1394 developer and implementor communities explicitly disavow any 1395 authoritative role in the ecosystem, and the implementations attempt 1396 very few mitigations against abuse, permitting republication of even 1397 cryptographically invalid OpenPGP packets. Clearer warnings to end 1398 users might reduce this kind of misperception. Or the community 1399 could encourage the removal of frequently misinterpreted user 1400 interfaces. 1402 16. IANA Considerations 1404 This document asks IANA to register two entries in the OpenPGP 1405 Notation IETF namespace, both with a reference to this document: 1407 o the "ksok" notation is defined in Section 10. 1409 o the "uidhash" notation is defined in Section 5.1.3. 1411 17. Document Considerations 1413 [ RFC Editor: please remove this section before publication ] 1415 This document is currently edited as markdown. Minor editorial 1416 changes can be suggested via merge requests at 1417 https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore or by 1418 e-mail to the author. Please direct all significant commentary to 1419 the public IETF OpenPGP mailing list: openpgp@ietf.org 1421 17.1. Document History 1423 substantive changes between -01 and -02: 1425 o distinguish different forms of flooding attack 1427 o distinguish toxic data as distinct from flooding 1429 o retrieval-time mitigations 1431 o user ID redaction 1433 o references to related work (CT, keylist, CONIKS, key transparency, 1434 ledgers/"blockchain", etc) 1436 o more details about UI/UX 1438 substantive changes between -00 and -01: 1440 o split out Contextual and Non-Append-Only mitigations 1442 o documented several other mitigations, including: 1444 * Decline Data From the Future 1446 * Blocklist 1448 * Exterior Process 1450 * Designated Authorities 1452 * Known Certificates 1454 * Rate-Limiting 1456 * Scoped User IDs 1458 o documented Updates-Only Keystores 1460 o consider three different kinds of flooding 1462 o deeper discussion of privacy considerations 1464 o better documentation of Reason for Revocation 1465 o document user ID conventions 1467 18. Acknowledgements 1469 This document is the result of years of operational experience and 1470 observation, as well as conversations with many different people - 1471 users, implementors, keystore operators, etc. A non-exhaustive list 1472 of people who have contriubuted ideas or nuance to this document 1473 specifically includes: 1475 o Antoine Beaupre 1477 o ilf 1479 o Jamie McClelland 1481 o Jonathan McDowell 1483 o Justus Winter 1485 o Marcus Brinkmann 1487 o Micah Lee 1489 o Neal Walfield 1491 o Phil Pennock 1493 o vedaal 1495 o Vincent Breitmoser 1497 o Wiktor Kwapisiewicz 1499 19. References 1501 19.1. Normative References 1503 [I-D.ietf-openpgp-rfc4880bis] 1504 Koch, W., carlson, b., Tse, R., and D. Atkins, "OpenPGP 1505 Message Format", draft-ietf-openpgp-rfc4880bis-06 (work in 1506 progress), November 2018. 1508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1509 Requirement Levels", BCP 14, RFC 2119, 1510 DOI 10.17487/RFC2119, March 1997, 1511 . 1513 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1514 Thayer, "OpenPGP Message Format", RFC 4880, 1515 DOI 10.17487/RFC4880, November 2007, 1516 . 1518 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1519 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1520 May 2017, . 1522 19.2. Informative References 1524 [BITCOIN] "Bitcoin", n.d., . 1526 [CONIKS] Felten, E., Freedman, M., Melara, M., Blankstein, A., and 1527 J. Bonneau, "CONIKS Key Management System", n.d., 1528 . 1530 [DEBIAN-KEYRING] 1531 McDowell, J., "Debian Keyring", n.d., 1532 . 1534 [GnuPG] Koch, W., "Using the GNU Privacy Guard", n.d., 1535 . 1537 [I-D.koch-openpgp-webkey-service] 1538 Koch, W., "OpenPGP Web Key Directory", draft-koch-openpgp- 1539 webkey-service-07 (work in progress), November 2018. 1541 [I-D.mccain-keylist] 1542 McCain, R., Lee, M., and N. Welch, "Distributing OpenPGP 1543 Key Fingerprints with Signed Keylist Subscriptions", 1544 draft-mccain-keylist-04 (work in progress), March 2019. 1546 [I-D.shaw-openpgp-hkp] 1547 Shaw, D., "The OpenPGP HTTP Keyserver Protocol (HKP)", 1548 draft-shaw-openpgp-hkp-00 (work in progress), March 2003. 1550 [KEY-TRANSPARENCY] 1551 Belvin, G. and R. Hurst, "Key Transparency, a transparent 1552 and secure way to look up public keys", n.d., 1553 . 1555 [MAILVELOPE-KEYSERVER] 1556 Oberndoerfer, T., "Mailvelope Keyserver", n.d., 1557 . 1559 [MONKEYSPHERE] 1560 Gillmor, D. and J. Rollins, "Monkeysphere", n.d., 1561 . 1563 [PARCIMONIE] 1564 Intrigeri, ., "Parcimonie", n.d., 1565 . 1568 [PGP-GLOBAL-DIRECTORY] 1569 Symantec Corporation, "PGP Global Directory Key 1570 Verification Policy", 2011, 1571 . 1574 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1575 DOI 10.17487/RFC5322, October 2008, 1576 . 1578 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 1579 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 1580 . 1582 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 1583 (DANE) Bindings for OpenPGP", RFC 7929, 1584 DOI 10.17487/RFC7929, August 2016, 1585 . 1587 [SKS] Minsky, Y., Fiskerstrand, K., and P. Pennock, "SKS 1588 Keyserver Documentation", March 2018, 1589 . 1592 [TOR] "The Tor Project", n.d., . 1594 Author's Address 1596 Daniel Kahn Gillmor 1597 American Civil Liberties Union 1598 125 Broad St. 1599 New York, NY 10004 1600 USA 1602 Email: dkg@fifthhorseman.net