idnits 2.17.00 (12 Aug 2021) /tmp/idnits15038/draft-dkg-openpgp-abuse-resistant-keystore-01.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 594 has weird spacing: '...ct (by remov...' == Line 597 has weird spacing: '..., this remov...' == Line 598 has weird spacing: '... any signat...' == Line 599 has weird spacing: '...revoked signa...' -- The document date (April 06, 2019) is 1141 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 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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 06, 2019 5 Expires: October 8, 2019 7 Abuse-Resistant OpenPGP Keystores 8 draft-dkg-openpgp-abuse-resistant-keystore-01 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 any third-party can add certifications with any 19 content to any OpenPGP certificate, the assembled/merged form of a 20 certificate can become unwieldy or undistributable. 22 This draft documents techniques that an archive of OpenPGP 23 certificates can use to mitigate the impact of these various forms of 24 flooding attacks. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 8, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 64 2.1. Certificate Flooding . . . . . . . . . . . . . . . . . . 6 65 2.2. User ID Flooding . . . . . . . . . . . . . . . . . . . . 6 66 2.3. Keystore Flooding . . . . . . . . . . . . . . . . . . . . 7 67 3. Simple Mitigations . . . . . . . . . . . . . . . . . . . . . 7 68 3.1. Decline Large Packets . . . . . . . . . . . . . . . . . . 7 69 3.2. Enforce Strict User IDs . . . . . . . . . . . . . . . . . 8 70 3.3. Scoped User IDs . . . . . . . . . . . . . . . . . . . . . 8 71 3.4. Strip or Standardize Unhashed Subpackets . . . . . . . . 8 72 3.5. Decline User Attributes . . . . . . . . . . . . . . . . . 9 73 3.6. Decline Non-exportable Certifications . . . . . . . . . . 9 74 3.7. Decline Data From the Future . . . . . . . . . . . . . . 9 75 3.8. Accept Only Profiled Certifications . . . . . . . . . . . 9 76 3.9. Accept Only Certificates Issued by Designated Authorities 10 77 3.10. Decline Packets by Blocklist . . . . . . . . . . . . . . 10 78 4. Contextual Mitigations . . . . . . . . . . . . . . . . . . . 11 79 4.1. Accept Only Cryptographically-verifiable Certifications . 11 80 4.2. Accept Only Certificates Issued by Known Certificates . . 11 81 4.3. Rate-limit Submissions by IP Address . . . . . . . . . . 12 82 4.4. Accept Certiifcates Based on Exterior Process . . . . . . 12 83 4.5. Accept Certificates by E-mail Validation . . . . . . . . 12 84 5. Non-append-only mitigations . . . . . . . . . . . . . . . . . 13 85 5.1. Drop Superseded Signatures . . . . . . . . . . . . . . . 13 86 5.2. Drop Expired Signatures . . . . . . . . . . . . . . . . . 14 87 5.3. Drop Dangling User IDs, User Attributes, and Subkeys . . 14 88 5.4. Drop All Other Elements of a Directly-Revoked Certificate 14 89 5.5. Implicit Expiration Date . . . . . . . . . . . . . . . . 15 90 6. Updates-only Keystores . . . . . . . . . . . . . . . . . . . 15 91 7. First-party-only Keystores . . . . . . . . . . . . . . . . . 16 92 8. First-party-attested Third-party Certifications . . . . . . . 16 93 8.1. Key Server Preferences "No-modify" . . . . . . . . . . . 17 94 8.2. Client Interactions . . . . . . . . . . . . . . . . . . . 18 95 9. Side Effects and Ecosystem Impacts . . . . . . . . . . . . . 18 96 9.1. Designated Revoker . . . . . . . . . . . . . . . . . . . 18 97 9.2. Certification-capable Subkeys . . . . . . . . . . . . . . 18 98 9.3. Assessing Certificates in the Past . . . . . . . . . . . 19 99 10. OpenPGP details . . . . . . . . . . . . . . . . . . . . . . . 19 100 10.1. Revocations . . . . . . . . . . . . . . . . . . . . . . 19 101 10.2. User ID Conventions . . . . . . . . . . . . . . . . . . 20 102 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 103 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 104 12.1. Publishing Identity Information . . . . . . . . . . . . 22 105 12.2. Social Graph . . . . . . . . . . . . . . . . . . . . . . 22 106 12.3. Tracking Clients by Queries . . . . . . . . . . . . . . 22 107 12.4. Cleartext Queries . . . . . . . . . . . . . . . . . . . 23 108 12.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 23 109 13. User Considerations . . . . . . . . . . . . . . . . . . . . . 24 110 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 111 15. Document Considerations . . . . . . . . . . . . . . . . . . . 24 112 15.1. Document History . . . . . . . . . . . . . . . . . . . . 24 113 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 114 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 115 17.1. Normative References . . . . . . . . . . . . . . . . . . 25 116 17.2. Informative References . . . . . . . . . . . . . . . . . 26 117 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 119 1. Introduction 121 1.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 1.2. Terminology 131 o "OpenPGP certificate" (or just "certificate") is used 132 interchangeably with [RFC4880]'s "Transferable Public Key". The 133 term "certificate" refers unambiguously to the entire composite 134 object, unlike "key", which might also be used to refer to a 135 primary key or subkey. 137 o An "identity certification" (or just "certification") is an 138 [RFC4880] signature packet that covers OpenPGP identity 139 information - that is, any signature packet of type 0x10, 0x11, 140 0x12, or 0x13. Certifications are said to (try to) "bind" a 141 primary key to a User ID. 143 o The primary key that makes the certification is known as the 144 "issuer". The primary key over which the certification is made is 145 known as the "subject". 147 o A "first-party certification" is issued by the primary key of a 148 certificate, and binds itself to a user ID in the certificate. 149 That is, the issuer is the same as the subject. This is sometimes 150 referred to as a "self-sig". 152 o A "third-party certification" is a made over a primary key and 153 user ID by some other certification-capable primary key. That is, 154 the issuer is different than the subject. (The elusive "second- 155 party" is presumed to be the verifier who is trying to interpret 156 the certificate) 158 o A "keystore" is any collection of OpenPGP certificates. Keystores 159 typically receive mergeable updates over the course of their 160 lifetime which might add to the set of OpenPGP certificates they 161 hold, or update the certificates. 163 o "Certificate discovery" is the process whereby a user retrieves an 164 OpenPGP certificate based on user ID (see Section 10.2). A user 165 attempting to discover a certificate from a keystore will search 166 for a substring of the known user IDs, most typically an e-mail 167 address if the user ID is an [RFC5322] name-addr or addr-spec. 168 Some certificate discovery mechanisms look for an exact match on 169 the known user IDs. [I-D.koch-openpgp-webkey-service] and 170 [I-D.shaw-openpgp-hkp] both offer certificate discovery 171 mechanisms. 173 o "Certificate validation" is the process whereby a user decides 174 whether a given user ID in an OpenPGP certificate is acceptable. 175 For example, if the certificate has a user ID of "Alice 176 " and the user wants to send an e-mail to 177 "alice@example.org", the mail user agent might want to ensure that 178 the certificate is valid for this e-mail address before encrypting 179 to it. This process can take different forms, and can consider 180 many different factors, some of which are not directly contained 181 in the certificate itself. For example, certificate validation 182 might consider whether the certificate was fetched via DANE 183 ([RFC7929]) or WKD ([I-D.koch-openpgp-webkey-service]); or whether 184 it has seen e-mails from that address signed by the certificate in 185 the past; or how long it has known about certificate. 187 o "Certificate update" is the process whereby a user fetches new 188 information about a certificate, potentially merging those OpnePGP 189 packets to change the status of the certificate. Updates might 190 include adding or revoking user IDs or subkeys, updating 191 expiration dates, or even revoking the entire certificate by 192 revoking the primary key directly. A user attempting to update a 193 certificate typically queries a keystore based on the 194 certificate's fingerprint. 196 o A "keyserver" is a particular kind of keystore, typically means of 197 publicly distributing OpenPGP certificates or updates to them. 198 Examples of keyserver software include [SKS] and 199 [MAILVELOPE-KEYSERVER]. One common HTTP interface for keyservers 200 is [I-D.shaw-openpgp-hkp]. 202 o A "synchronizing keyserver" is a keyserver which gossips with 203 other peers, and typically acts as an append-only log. Such a 204 keyserver is typically useful for certificate discovery, 205 certificate updates, and revocation information. They are 206 typically _not_ useful for certificate validation, since they make 207 no assertions about whether the identities in the certificates 208 they server are accurate. As of the writing of this document, 209 [SKS] is the canonical synchronizing keyserver implementation, 210 though other implementations exist. 212 o An "e-mail-validating keyserver" is a keyserver which attempts to 213 verify the identity in an OpenPGP certificate's user ID by 214 confirming access to the e-mail account, and possibly by 215 confirming access to the secret key. Some implementations permit 216 removal of a certificate by anyone who can prove access to the 217 e-mail address in question. They are useful for certificate 218 discovery based on e-mail address and certificate validation (by 219 users who trust the operator), but some may not be useful for 220 certificate update or revocation, since a certificate could be 221 simply replaced by an adversary who also has access to the e-mail 222 address in question. [MAILVELOPE-KEYSERVER] is an example of such 223 a keyserver. 225 o "Cryptographic validity" refers to mathematical evidence that a 226 signature came from the secret key associated with the public key 227 it claims to come from. Note that a certification may be 228 cryptographically valid without the signed data being true (for 229 example, a given certificate with the user ID "Alice 230 " might not belong to the person who controls 231 the e-mail address "alice@example.org" even though the self-sig is 232 cryptographically valid). In particular, cryptographic validity 233 for user ID in a certificate is typically insufficient evidence 234 for certificate validation. Also note that knowledge of the 235 public key of the issuer is necessary to determine whether any 236 given signature is cryptographically valid. Some keyservers 237 perform cryptographic validation in some contexts. Other 238 keyservers (like [SKS]) perform no cryptographic validation 239 whatsoever. 241 o OpenPGP revocations can have "Reason for Revocation" (see 242 [RFC4880]), which can be either "soft" or "hard". The set of 243 "soft" reasons is: "Key is superseded" and "Key is retired and no 244 longer used". All other reasons (and revocations that do not 245 state a reason) are "hard" revocations. See Section 10.1 for more 246 detail. 248 2. Problem Statement 250 OpenPGP keystores that handle submissions from the public are subject 251 to a range of flooding attacks by malicious submitters. 253 This section describes three distinct flooding attacks that public 254 keystores should consider. 256 The rest of the document describes some mitigations that can be used 257 by keystores that are concerned about these problems but want to 258 continue to offer some level of service for certificate discovery, 259 certificate update, or certificate validation. 261 2.1. Certificate Flooding 263 Many public keystores (including both the [SKS] keyserver network and 264 [MAILVELOPE-KEYSERVER]) allow anyone to attach arbitrary data (in the 265 form of third-party certifications) to any certificate, bloating that 266 certificate to the point of being impossible to effectively retrieve. 267 For example, some OpenPGP implementations simply refuse to process 268 certificates larger than a certain size. 270 This kind of Denial-of-Service attack makes it possible to make 271 someone else's certificate unretrievable from the keystore, 272 preventing certificate discovery. It also makes it possible to swamp 273 a certificate that has been revoked, preventing certificate update, 274 potentially leaving the client of the keystore with the compromised 275 certificate in an unrevoked state locally. 277 Additionally, even without malice, OpenPGP certificates can 278 potentially grow without bound. 280 2.2. User ID Flooding 282 Public keystores that are used for certificate discovery may also be 283 vulnerable to attacks that flood the space of known user IDs. In 284 particular, if the keystore accepts arbitrary certificates from the 285 public and does no verification of the user IDs, then any client 286 searching for a given user ID may need to review and process an 287 effectively unbounded set of maliciously-submitted certificates to 288 find the non-malicious certificates they are looking for. 290 For example, if an attacker knows that a given system consults a 291 keystore looking for certificates which match the e-mail address 292 "alice@example.org", the attacker may upload hundreds or thousands of 293 certificates containing user IDs that match that address. Even if 294 those certificates would not be accepted by a client (e.g., because 295 they were not certified by a known-good authority), the client 296 typically still has to wade through all of them in order to find the 297 non-malicious certificates. 299 If the keystore does not offer a discovery interface at all (that is, 300 if clients cannot search it by user ID), then user ID flooding is of 301 less consequence. 303 2.3. Keystore Flooding 305 A public keystore that accepts arbitrary OpenPGP material and is 306 append-only is at risk of being overwhelmed by sheer quantity of 307 malicious uploaded packets. This is a risk even if the user ID space 308 is not being deliberately flooded, and if individual certificates are 309 protected from flooding by any of the mechanisms described later in 310 this document. 312 The keystore itself can become difficult to operate if the total 313 quantity of data is too large, and if it is a synchronizing 314 keyserver, then the quantities of data may impose unsustainable 315 bandwidth costs on the operator as well. 317 Effectively mitigating against keystore flooding requires either 318 abandoning the append-only property that some keystores prefer, or 319 imposing very strict controls on initial ingestion. 321 3. Simple Mitigations 323 These steps can be taken by any keystore that wants to avoid 324 obviously malicious abuse. They can be implemented on receipt of any 325 new packet, and are based strictly on the structure of the packet 326 itself. 328 3.1. Decline Large Packets 330 While [RFC4880] permits OpenPGP packet sizes of arbitrary length, 331 OpenPGP certificates rarely need to be so large. An abuse-resistant 332 keystore SHOULD reject any OpenPGP packet larger than 8383 octets. 333 (This cutoff is chosen because it guarantees that the packet size can 334 be represented as a one- or two-octet [RFC4880] "New Format Packet 335 Length", but it could be reduced further) 337 This may cause problems for user attribute packets that contain large 338 images, but it's not clear that these images are concretely useful in 339 any context. Some keystores MAY extend this limit for user attribute 340 packets specifically, but SHOULD NOT allow even user attributes 341 packets larger than 65536 octets. 343 3.2. Enforce Strict User IDs 345 [RFC4880] indicates that User IDs are expected to be UTF-8 strings. 346 An abuse-resistant keystore MUST reject any user ID that is not valid 347 UTF-8. 349 Some abuse-resistant keystores MAY only accept User IDs that meet 350 even stricter conventions, such as an [RFC5322] name-addr or addr- 351 spec, or a URL like "ssh://host.example.org". 353 As simple text strings, User IDs don't need to be nearly as long as 354 any other packets. An abuse-resistant keystore SHOULD reject any 355 user ID packet larger than 1024 octets. 357 3.3. Scoped User IDs 359 Some abuse-resistant keystores may restrict themselves to publishing 360 only certificates with User IDs that match a specific pattern. For 361 example, [RFC7929] encourages publication in the DNS of only 362 certificates whose user IDs refer to e-mail addresses within the DNS 363 zone. [I-D.koch-openpgp-webkey-service] similarly aims to restrict 364 publication to certificates relevant to the specific e-mail domain. 366 3.4. Strip or Standardize Unhashed Subpackets 368 [RFC4880] signature packets contain an "unhashed" block of 369 subpackets. These subpackets are not covered by any cryptographic 370 signature, so they are ripe for abuse. 372 An abuse-resistant keysetore SHOULD strip out all unhashed 373 subpackets. 375 Note that some certifications only identify the issuer of the 376 certification by an unhashed Issuer ID subpacket. If a 377 certification's hashed subpacket section has no Issuer ID or Issuer 378 Fingerprint (see [I-D.ietf-openpgp-rfc4880bis]) subpacket, then an 379 abuse-resistant keystore that has cryptographically validated the 380 certification SHOULD make the unhashed subpackets contain only a 381 single subpacket. That subpacket should be of type Issuer 382 Fingerprint, and should contain the fingerprint of the issuer. 384 A special exception may be made for unhashed subpackets in a third- 385 party certification that contain attestations from the certificate's 386 primary key as described in Section 8. 388 3.5. Decline User Attributes 390 Due to size concerns, some abuse-resistant keystores MAY choose to 391 ignore user attribute packets entirely, as well as any certifications 392 that cover them. 394 3.6. Decline Non-exportable Certifications 396 An abuse-resistant keystore MUST NOT accept any certification that 397 has the "Exportable Certification" subpacket present and set to 0. 398 While most keystore clients will not upload these "local" 399 certifications anyway, a reasonable public keystore that wants to 400 minimize data has no business storing or distributing these 401 certifications. 403 3.7. Decline Data From the Future 405 Many OpenPGP packets have time-of-creation timestamps in them. An 406 abuse-resistant keystore with a functional real-time clock MAY decide 407 to only accept packets whose time-of-creation is in the future. 409 Note that some OpenPGP implementations may pre-generate OpenPGP 410 material intended for use only in some future window (e.g. "Here is 411 the certificate we plan to use to sign our software next year; do not 412 accept signatures from it until then."), and may use modified time- 413 of-creation timestamps to try to acheive that purpose. This material 414 would not be distributable ahead of time by an abuse-resistant 415 keystore that adopts this mitigation. 417 3.8. Accept Only Profiled Certifications 419 An aggressively abuse-resistant keystore MAY decide to only accept 420 certifications that meet a specific profile. For example, it MAY 421 reject certifications with unknown subpacket types, unknown 422 notations, or certain combinations of subpackets. This can help to 423 minimize the amount of room for garbage data uploads. 425 Any abuse-resistant keystore that adopts such a strict posture should 426 clearly document what its expected certificate profile is, and should 427 have a plan for how to extend the profile if new types of 428 certification appear that it wants to be able to distribute. 430 Note that if the profile is ever restricted (rather than extended), 431 and the restriction is applied to the material already present, such 432 a keystore is no longer append-only (please see Section 5). 434 3.9. Accept Only Certificates Issued by Designated Authorities 436 An abuse-resistant keystore capable of cryptographic validation MAY 437 retain a list of designated authorities, typically in the form of a 438 set of known public keys. Upon receipt of a new OpenPGP certificate, 439 the keystore can decide whether to accept or decline each user ID of 440 the certificate based whether that user ID has a certification that 441 was issued by one or more of the designated authorities. 443 If no user IDs are certified by designated authority, such a keystore 444 SHOULD decline the certificate and its primary key entirely. Such a 445 keystore SHOULD decline to retain or propagate all certifications 446 associated with each accepted user ID except for first-party 447 certifications and certifications by the designated authorities. 449 The operator of such a keystore SHOULD have a clear policy about its 450 set of designated authorities. 452 Given the ambiguities about expiration and revocation, such a 453 keyserver SHOULD ignore expiration and revocation of authority 454 certifications, and simply accept and retain as long as the 455 cryptographic signature is valid. 457 Note that if any key is removed from the set of designated 458 authorities, and that change is applied to the existing keystore, 459 such a keystore may no longer be append-only (please see Section 5). 461 3.10. Decline Packets by Blocklist 463 The maintainer of the keystore may keep a specific list of "known- 464 bad" material, and decline to accept or redistribute items matching 465 that blocklist. The material so identified could be anything, but 466 most usefully, specific public keys or User IDs could be blocked. 468 Note that if a blocklist grows to include an element already present 469 in the keystore, it will no longer be append-only (please see 470 Section 5). 472 Some keystores may choose to apply a blocklist only at distribution 473 time and not apply it at input time. This allows the keystore to be 474 append-only, and permits synchronization between keystores that don't 475 share a blocklist, and somewhat reduces the attacker's incentive for 476 flooding the keystore. 478 Note that development and maintenance of a blocklist is not without 479 its own potentials for abuse. For one thing, the blocklist may 480 itself grow without bound. Additionally, a blocklist may be socially 481 or politically contentious. There needs to be a clear policy about 482 how it is managed, whether by delegation to specific decision-makers, 483 or explicit tests. Furthermore, the existence of even a well- 484 intentioned blocklist may be an "attractive nuisance," drawing the 485 interest of would-be censors or other attacker interested in 486 controlling the ecosystem reliant on the keystore in question. 488 4. Contextual Mitigations 490 Some mitigations make the acceptance or rejection of packets 491 contingent on data that is already in the keystore or the keystore's 492 developing knowledge about the world. This means that, depending on 493 the order that the keystore encounters the various material, or how 494 it discovers the material, the final set of material retained and 495 distributed by the keystore might be different. 497 While this isn't necessarily bad, it may be a surprising property for 498 some users of keystores. 500 4.1. Accept Only Cryptographically-verifiable Certifications 502 An abuse-resistant keystore that is capable of doing cryptographic 503 validation MAY decide to reject certifications that it cannot 504 cryptographically validate. 506 This may mean that the keystore rejects some packets while it is 507 unaware of the public key of the issuer of the packet. 509 4.2. Accept Only Certificates Issued by Known Certificates 511 This is an extension of Section 3.9, but where the set of authorities 512 is just the set of certificates already known to the keystore. An 513 abuse-resistant keystore that adopts this strategy is effectively 514 only crawling the reachable graph of OpenPGP certificates from some 515 starting core. 517 A keystore adopting the mitigation SHOULD have a clear documentation 518 of the core of initial certificates it starts with, as this is 519 effectively a policy decision. 521 This mitigation measure may fail due to a compromise of any secret 522 key that is associated with a primary key of a certificate already 523 present in the keystore. Such a compromise permits an attacker to 524 flood the rest of the network. In the event that such a compromised 525 key is identified, it might be placed on a blocklist (see 526 Section 3.10). In particular, if a public key is added to a 527 blocklist for a keystore implementing this mitigation, and it is 528 removed from the keystore, then all certificates that were only 529 "reachable" from the blocklisted certificate should also be 530 simultaneously removed. 532 4.3. Rate-limit Submissions by IP Address 534 Some OpenPGP keystores accept material from the general public over 535 the Internet. If an abuse-resistant keystore observes a flood of 536 material submitted to the keystore from a given Internet address, it 537 MAY choose to throttle submissions from that address. When receiving 538 submissions over IPv6, such a keystore MAY choose to throttle entire 539 nearby subnets, as a malicious IPv6 host is more likely to have 540 multiple addresses. 542 This requires that the keystore maintain state about recent 543 submissions over time and address. It may also be problematic for 544 users who appear to share an IP address from the vantage of the 545 keystore, including those beind a NAT, using a VPN, or accessing the 546 keystore via Tor. 548 4.4. Accept Certiifcates Based on Exterior Process 550 Some public keystores resist abuse by explicitly filtering OpenPGP 551 material based on a set of external processes. For example, 552 [DEBIAN-KEYRING] adjudicates the contents of the "Debian keyring" 553 keystore based on organizational procedure and manual inspection. 555 4.5. Accept Certificates by E-mail Validation 557 Some keystores resist abuse by declining any certificate until the 558 user IDs have been verified by e-mail. When these "e-mail- 559 validating" keystores review a new certificate that has a user ID 560 with an e-mail address in it, they send an e-mail to the associated 561 address with a confirmation mechanism (e.g., a high-entropy HTTPS URL 562 link) in it. In some cases, the e-mail itself is encrypted to an 563 encryption-capable key found in the proposed certificate. If the 564 keyholder triggers the confirmation mechanism, then the keystore 565 accepts the certificate. 567 [PGP-GLOBAL-DIRECTORY] describes some concerns held by a keystore 568 operator using this approach. [MAILVELOPE-KEYSERVER] is another 569 example. 571 5. Non-append-only mitigations 573 The following mitigations may cause some previously-retained packets 574 to be dropped after the keystore receives new information, or as time 575 passes. This is entirely reasonable for some keystores, but it may 576 be surprising for any keystore that expects to be append-only (for 577 example, some keyserver synchronization techniques may expect this 578 property to hold). 580 Furthermore, keystores that drop old data, or certifications that are 581 superseded may make it difficult or impossible for their users to 582 reason about the validity of signatures that were made in the past. 583 See Section 9.3 for more considerations. 585 Note also that many of these mitigations depend on cryptographic 586 validation, so they're typically contextual as well. 588 A keystore that needs to be append-only, or which cannot perform 589 cryptographic validation MAY omit these mitigations. 591 Note that [GnuPG] anticipates some of these suggestions with its 592 "clean" subcommand, which is documented as: 594 Compact (by removing all signatures except the selfsig) 595 any user ID that is no longer usable (e.g. revoked, or 596 expired). Then, remove any signatures that are not usable 597 by the trust calculations. Specifically, this removes 598 any signature that does not validate, any signature that 599 is superseded by a later signature, revoked signatures, 600 and signatures issued by keys that are not present on the 601 keyring. 603 5.1. Drop Superseded Signatures 605 An abuse-resistant keystore SHOULD drop all signature packets that 606 are explicitly superseded. For example, there's no reason to retain 607 or distribute a self-sig by key K over User ID U from 2017 if the 608 keystore have a cryptographically-valid self-sig over from 609 2019. 611 Note that this covers both certifications and signatures over 612 subkeys, as both of these kinds of signature packets may be 613 superseded. 615 Getting this right requires a nuanced understanding of subtleties in 616 [RFC4880] related to timing and revocation. 618 5.2. Drop Expired Signatures 620 If a signature packet is known to only be valid in the past, there is 621 no reason to distribute it further. An abuse-resistant keystore with 622 access to a functionally real-time clock SHOULD drop all 623 certifications and subkey signature packets with an expiration date 624 in the past. 626 Note that this assumes that the keystore and its clients all have 627 roughly-synchronized clocks. If that is not the case, then there 628 will be many other problems! 630 5.3. Drop Dangling User IDs, User Attributes, and Subkeys 632 If enough signature packets are dropped, it's possible that some of 633 the things that those signature packets cover are no longer valid. 635 An abuse-resistant keystore which has dropped all certifications that 636 cover a User ID SHOULD also drop the User ID packet. 638 Note that a User ID that becomes invalid due to revocation MUST NOT 639 be dropped, because the User ID's revocation signature itself remains 640 valid, and needs to be distributed. 642 A primary key with no User IDs and no subkeys and no revocations MAY 643 itself also be removed from distribution, though note that the 644 removal of a primary key may make it impossible to cryptographically 645 validate other certifications held by the keystore. 647 5.4. Drop All Other Elements of a Directly-Revoked Certificate 649 If the primary key of a certiifcate is revoked via a direct key 650 signature, an abuse-resistant keystore SHOULD drop all the rest of 651 the associated data (user IDs, user attributes, and subkeys, and all 652 attendant certifications and subkey signatures). This defends 653 against an adversary who compromises a primary key and tries to flood 654 the certificate to hide the revocation. 656 Note that the direct key revocation signature MUST NOT be dropped. 658 In the event that an abuse-resistant keystore is flooded with direct 659 key revocation signatures, it should retain the hardest, earliest 660 revocation (see also Section 10.1). 662 In particular, if any of the direct key revocation signatures is a 663 "hard" revocation, the abuse-resistant keystore SHOULD retain the 664 earliest such revocation signature (by signature creation date). 666 Otherwise, the abuse-resistant keystore SHOULD retain the earliest 667 "soft" direct key revocation signature it has seen. 669 If either of the above date comparisons results in a tie between two 670 revocation signatures of the same "hardness", an abuse-resistant 671 keystore SHOULD retain the signature that sorts earliest based on a 672 binary string comparison of the direct key revocation signature 673 packet itself. 675 5.5. Implicit Expiration Date 677 In combination with some of the dropping mitigations above, a 678 particularly aggressive abuse-resistant keystore MAY choose an 679 implicit expiration date for all signature packets. For example, a 680 signature packet that claims no expiration could be treated by the 681 keystore as expiring 3 years after issuance. This would permit the 682 keystore to eject old packets on a rolling basis. 684 FIXME: it's not clear what should happen with signature packets 685 marked with an explicit expiration that is longer than implicit 686 maximum. Should it be capped to the implicit date, or accepted? 688 Warning: This idea is pretty radical, and it's not clear what it 689 would do to an ecosystem that depends on such a keystore. It 690 probably needs more thinking. 692 6. Updates-only Keystores 694 In addition to the mitigations above, some keystores may resist abuse 695 by declining to accept any user IDs or certifications whatsoever. 697 Such a keystore MUST be capable of cryptographic validation. It 698 accepts primary key packets, cryptographically-valid direct-key 699 signatures from a primary key over itself, subkeys and their 700 cryptographically-validated binding signatures (and cross signatures, 701 where necessary). 703 Clients of an updates-only keystore cannot possibly use the keystore 704 for certificate discovery, because there are no user IDs to match. 705 However, they can use it for certificate update, as it's possible to 706 ship revocations (which are direct key signatures), new subkeys, 707 updates to subkey expiration, subkey revocation, and direct key 708 signature-based certificate expiration updates. 710 Note that many popular OpenPGP implemenations do not implement direct 711 primary key expiration mechanisms, relying instead on user ID 712 expirations. These user ID expiration dates or other metadata 713 associated with a self-certification will not be distributed by an 714 updates-only keystore. 716 Certificates shipped by an updates-only keystore are technically 717 invalid [RFC4880] "transferable public keys," because they lack a 718 user ID packet. However many OpenPGP implementations will accept 719 such a certificate if they already know of a user ID for the 720 certificate, because the composite certificate resulting from a merge 721 will be a standards-compliant transferable public key. 723 7. First-party-only Keystores 725 Slightly more permissive than the updates-only keystore described in 726 Section 6 is a keystore that also permits user IDs and their self- 727 sigs. 729 A first-party-only keystore only accepts and distributes 730 cryptographically-valid first-party certifications. Given a primary 731 key that the keystore understands, it will only attach user IDs that 732 have a valid self-sig, and will only accept and re-distribute subkeys 733 that are also cryptographically valid (including requiring cross-sigs 734 for signing-capable subkeys as recommended in [RFC4880]). 736 This effectively solves the problem of abusive bloating attacks on 737 any certificate, because the only party who can make a certificate 738 overly large is the holder of the secret corresponding to the primary 739 key itself. 741 However, a first-party-only keystore is still problematic for those 742 people who rely on the keystore for discovery of third-party 743 certifications. Section 8 attempts to address this lack. 745 8. First-party-attested Third-party Certifications 747 We can augment a first-party-only keystore to allow it to distribute 748 third-party certifications as long as the first-party has signed off 749 on the specific third-party certification. 751 An abuse-resistant keystore SHOULD only accept a third-party 752 certification if it meets the following criteria: 754 o The third-party certification MUST be cryptographically valid. 755 Note that this means that the keystore needs to know the primary 756 key for the issuer of the third-party certification. 758 o The third-party certification MUST have an unhashed subpacket of 759 type Embedded Signature, the contents of which we'll call the 760 "attestation". This attestation is from the certificate's primary 761 key over the third-party certification itself, as detailed in the 762 steps below: 764 o The attestation MUST be an OpenPGP signature packet of type 0x50 765 (Third-Party Confirmation signature) 767 o The attestation MUST contain a hashed "Issuer Fingerprint" 768 subpacket with the fingerprint of the primary key of the 769 certificate in question. 771 o The attestation MUST NOT be marked as non-exportable. 773 o The attestation MUST contain a hashed Notation subpacket with the 774 name "ksok", and an empty (0-octet) value. 776 o The attestation MUST contain a hashed "Signature Target" subpacket 777 with "public-key algorithm" that matches the public-key algorithm 778 of the third-party certification. 780 o The attestation's hashed "Signature Target" subpacket MUST use a 781 reasonably strong hash algorithm (as of this writing, any 782 [RFC4880] hash algorithm except MD5, SHA1, or RIPEMD160), and MUST 783 have a hash value equal to the hash over the third-party 784 certification with all unhashed subpackets removed. 786 o The attestation MUST be cryptographically valid, verifiable by the 787 primary key of the certificate in question. 789 What this means is that a third-party certificate will only be 790 accepted/distributed by the keystore if: 792 o the keystore knows about both the first- and third-parties. 794 o the third-party has made the identity assertion 796 o the first-party has confirmed that they're OK with the third-party 797 certification being distributed by any keystore. 799 FIXME: it's not clear whether the "ksok" notification is necessary - 800 it's in place to avoid some accidental confusion with any other use 801 of the Third-Party Confirmation signature packet type, but the author 802 does not know of any such use that might collide. 804 8.1. Key Server Preferences "No-modify" 806 [RFC4880] defines "Key Server Preferences" with a "No-modify" bit. 807 That bit has never been respected by any keyserver implementation 808 that the author is aware of. This section effectively asks an abuse- 809 resistant keystore to treat that bit as always set, whether it is 810 present in the certificate or not. 812 8.2. Client Interactions 814 The multi-stage layer of creating such an attestation (certificate 815 creation by the first-party, certification by the third-party, 816 attestation by the first-party, then handoff to the keystore) may 817 represent a usability obstacle to a user who needs a third-party- 818 certified OpenPGP certificate. 820 No current OpenPGP client can easily create the attestions described 821 in this section. More implementation work needs to be done to make 822 it easy (and understandable) for a user to perform this kind of 823 attestation. 825 9. Side Effects and Ecosystem Impacts 827 9.1. Designated Revoker 829 A first-party-only keystore as described in Section 7 might decline 830 to distribute revocations made by the designated revoker. This is a 831 risk to certificate-holder who depend on this mechanism, because an 832 important revocation might be missed by clients depending on the 833 keystore. 835 FIXME: adjust this document to point out where revocations from a 836 designated revoker SHOULD be propagated, maybe even in first-party- 837 only keystores. 839 9.2. Certification-capable Subkeys 841 Much of this discussion assumes that primary keys are the only 842 certification-capable keys in the OpenPGP ecosystem. Some proposals 843 have been put forward that assume that subkeys can be marked as 844 certification-capable. If subkeys are certification-capable, then 845 much of the reasoning in this draft becomes much more complex, as 846 subkeys themselves can be revoked by their primary key without 847 invalidating the key material itself. That is, a subkey can be both 848 valid (in one context) and invalid (in another context) at the same 849 time. So questions about what data can be dropped (e.g. in 850 Section 5) are much fuzzier, and the underlying assumptions may need 851 to be reviewed. 853 If some OpenPGP implementations accept certification-capable subkeys, 854 but an abuse-resistant keystore does not accept certifications from 855 subkeys in general, then interactions between that keystore and those 856 implementations may be surprising. 858 9.3. Assessing Certificates in the Past 860 Online protocols like TLS perform signature and certificate 861 evaluation based entirely on the present time. If a certificate that 862 signs a TLS handshake message is invalid now, it doesn't matter 863 whether it was valid a week ago, because the present TLS session is 864 the context of the evaluation. 866 But OpenPGP signatures are often evaluated at some temporal remove 867 from when the signature was made. For example, software packages are 868 signed at release time, but those signatures are validated at 869 download time. 871 Further complicating matters, the composable nature of an OpenPGP 872 certificate means that the certificate associated with any particular 873 signing key (primary key or subkey) can transform over time. So when 874 evaluating a signature that appears to have been made by a given 875 certificate, it may be better to try to evaluate the certificate at 876 the time the signature was made, rather than the present time. 878 When evaluating a certificate at a time T in the past, one approach 879 is to discard all packets with a creation time later than T, and then 880 evaluate the resulting certificate from the remaining packets in the 881 context of time T. 883 However, any such evaluator SHOULD NOT ignore "hard" OpenPGP key 884 revocations, regardless of their creation date. (see Section 10.1). 886 If a non-append-only keystore (Section 5) has dropped superseded 887 (Section 5.1) or expired (Section 5.2) certifications, it's possible 888 for the certificate composed of the remaining packets to have no 889 valid first-party certification at the time that a given signature 890 was made. Such a certificate would be invalid according to 891 [RFC4880]. 893 10. OpenPGP details 895 This section collects details about common OpenPGP implementation 896 behavior that are useful in evaluating and reasoning about OpenPGP 897 certificates. 899 10.1. Revocations 901 It's useful to classify OpenPGP revocations of key material into two 902 categories: "soft" and "hard". 904 If the "Reason for Revocation" of an OpenPGP key is either "Key is 905 superseded" or "Key is retired and no longer used", it is a "soft" 906 revocation. 908 An implementation that interprets a "soft" revocation will typically 909 not invalidate signatures made by the associated key with a creation 910 date that predates the date of the soft revocation. A "soft" 911 revocation in some ways behaves like a non-overridable expiration 912 date. 914 All other revocations of OpenPGP keys (with any other Reason for 915 Revocation, or with no Reason for Revocation at all) should be 916 considered "hard". 918 The presence of a "hard" revocation of an OpenPGP key indicates that 919 the user should reject all signatures and certifications made by that 920 key, regardless of the creation date of the signature. 922 Note that some OpenPGP implementations do not distinguish between 923 these two categories. 925 A defensive OpenPGP implementation that does not distinguish between 926 these two categories SHOULD treat all revocations as "hard". 928 An implementation aware of a "soft" revocation or of key or 929 certificate expiry at time T SHOULD accept and process a "hard" 930 revocation even if it appears to have been issued at a time later 931 than T. 933 10.2. User ID Conventions 935 [RFC4880] requires a user ID to be a UTF-8 string, but does not 936 constrain it beyond that. In practice, a handful of conventions 937 predominate in how User IDs are formed. 939 The most widespread convention is a name-addr as defined in 940 [RFC5322]. For example: 942 Alice Jones 944 But a growing number of OpenPGP certificates contain user IDs that 945 are instead a raw [RFC5322] addr-spec, omitting the display-name and 946 the angle brackets entirely, like so: 948 alice@example.org 949 Some certificates have user IDs that are simply "normal" human names 950 (perhaps display-name in [RFC5322] jargon, though not necessarily 951 conforming to a specific ABNF). For example: 953 Alice Jones 955 Still other certificates identify a particular network service by 956 scheme and hostname. For example, the administrator of an ssh host 957 participating in the [MONKEYSPHERE] might choose a user ID for the 958 OpenPGP representing the host like so: 960 ssh://foo.example.net 962 11. Security Considerations 964 This document offers guidance on mitigating a range of denial-of- 965 service attacks on public keystores, so the entire document is in 966 effect about security considerations. 968 Many of the mitigations described here defend individual OpenPGP 969 certificates against flooding attacks (see Section 2.1). But only 970 some of these mitigations defend against flooding attacks against the 971 keystore itself (see Section 2.3), or against flooding attacks on the 972 space of possible user IDs (see Section 2.2). Thoughtful threat 973 modeling and monitoring of the keystore and its defenses are probably 974 necessary to maintain the long-term health of the keystore. 976 Section 9.1 describes a potentially scary security problem for 977 designated revokers. 979 Note that there is an inherent tension between accepting arbitrary 980 certificate uploads and permitting effective certificate discovery. 981 If a keystore accepts arbitrary certificate uploads for 982 redistribution, it appears to be vulnerable to user ID flooding 983 (Section 2.2), which makes it difficult or impossible to rely on for 984 certificate discovery. 986 TODO (more security considerations) 988 12. Privacy Considerations 990 Keystores themselves raise a host of potential privacy concerns. 991 Additional privacy concerns are raised by traffic to and from the 992 keystores. This section tries to outline some of the risks to the 993 privacy of people whose certificates are stored and redistributed in 994 public keystores, as well as risks to the privacy of people who make 995 use of the key stores for certificate discovery or certificate 996 update. 998 TODO (more privacy considerations) 1000 12.1. Publishing Identity Information 1002 Public OpenPGP keystores often distribute names or e-mail addresses 1003 of people. Some people do not want their names or e-mail addresses 1004 distributed in a public keystore, or may change their minds about it 1005 at some point. Append-only keystores are particularly problematic in 1006 that regard. The mitigation in Section 5.4 can help such users strip 1007 their details from keys that they control. However, if an OpenPGP 1008 certificate with their details is uploaded to a keystore, but is not 1009 under their control, it's unclear what mechanisms can be used to 1010 remove the certificate that couldn't also be exploited to take down 1011 an otherwise valid certificate. 1013 An updates-only keyserver (Section 6) avoids this particular privacy 1014 concern because it distributes no user IDs at all. 1016 12.2. Social Graph 1018 Third-party certifications effectively map out some sort of social 1019 graph. A certification asserts a statement of belief by the issuer 1020 that the real-world party identified by the user ID is in control of 1021 the subject cryptographic key material. But those connections may be 1022 potentially sensitive, and some people may not want these maps built. 1024 A first-party-only keyserver (Section 7) avoids this privacy concern 1025 because it distribues no third-party privacy concern. 1027 First-party attested third-party certifications described in 1028 Section 8 are even more relevant edges in the social graph, because 1029 their bidirectional nature suggests that both parties are aware of 1030 each other, and see some value in mutual association. 1032 12.3. Tracking Clients by Queries 1034 Even without third-party certifications, the acts of certificate 1035 discovery and certificate update represent a potential privacy risk, 1036 because the keystore queried gets to learn which user IDs (in the 1037 case of discovery) or which certificates (in the case of update) the 1038 client is interested in. In the case of certificate update, if a 1039 client attempts to update all of its known certificates from the same 1040 keystore, that set is likely to be a unique set, and therefore 1041 identifies the client. A keystore that monitors the set of queries 1042 it receives might be able to profile or track those clients who use 1043 it repeatedly. 1045 Clients which want to to avoid such a tracking attack MAY try to 1046 perform certificate update from multiple different keystores. To 1047 hide network location, a client making a network query to a keystore 1048 SHOULD use an anonymity network like [TOR]. Tools like [PARCIMONIE] 1049 are designed to facilitate this type of certificate update. 1051 Keystores which permit public access and want to protect the privacy 1052 of their clients SHOULD NOT reject access from clients using [TOR] or 1053 comparable anonymity networks. Additionally, they SHOULD minimize 1054 access logs they retain. 1056 Alternately, some keystores may distribute their entire contents to 1057 any interested client, in what can be seen as the most trivial form 1058 of private information retrieval. [DEBIAN-KEYRING] is one such 1059 example; its contents are distributed as an operating system package. 1060 Clients can interrogate their local copy of such a keystore without 1061 exposing their queries to a third-party. 1063 12.4. Cleartext Queries 1065 If access to the keystore happens over observable channels (e.g., 1066 cleartext connections over the Internet), then a passive network 1067 monitor could perform the same type profiling or tracking attack 1068 against clients of the keystore described in Section 12.3. Keystores 1069 which offer network access SHOULD provide encrypted transport. 1071 12.5. Traffic Analysis 1073 Even if a keystore offers encrypted transport, the size of queries 1074 and responses may provide effective identification of the specific 1075 certificates fetched during discovery or update, leaving open the 1076 types of tracking attacks described in Section 12.3. Clients of 1077 keystores SHOULD pad their queries to increase the size of the 1078 anonymity set. And keystores SHOULD pad their responses. 1080 The appropriate size of padding to effectively anonymize traffic to 1081 and from keystores is likely to be mechanism- and cohort-specific. 1082 For example, padding for keystores accessed via the DNS ([RFC7929] 1083 may use different padding strategies that padding for keystores 1084 accessed over WKD ([I-D.koch-openpgp-webkey-service]), which may in 1085 turn be different from keystores accessed over HKPS 1086 ([I-D.shaw-openpgp-hkp]). A keystore which only accepts user IDs 1087 within a specific domain (e.g., Section 3.3) or which uses custom 1088 process (Section 4.4) for verification might have different padding 1089 criteria than a keystore that serves the general public. 1091 Specific padding policies or mechanisms are out of scope for this 1092 document. 1094 13. User Considerations 1096 Section 8.2 describes some outstanding work that needs to be done to 1097 help users understand how to produce and distribute a third-party- 1098 certified OpenPGP certificate to an abuse-resistant keystore. 1100 14. IANA Considerations 1102 This document asks IANA to register the "ksok" notation name in the 1103 OpenPGP Notation IETF namespace, with a reference to this document, 1104 as defined in Section 8. 1106 15. Document Considerations 1108 [ RFC Editor: please remove this section before publication ] 1110 This document is currently edited as markdown. Minor editorial 1111 changes can be suggested via merge requests at 1112 https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore or by 1113 e-mail to the author. Please direct all significant commentary to 1114 the public IETF OpenPGP mailing list: openpgp@ietf.org 1116 15.1. Document History 1118 substantive changes between -00 and -01: 1120 o split out Contextual and Non-Append-Only mitigations 1122 o documented several other mitigations, including: 1124 * Decline Data From the Future 1126 * Blocklist 1128 * Exterior Process 1130 * Designated Authorities 1132 * Known Certificates 1134 * Rate-Limiting 1136 * Scoped User IDs 1138 o documented Updates-Only Keystores 1140 o consider three different kinds of flooding 1141 o deeper discussion of privacy considerations 1143 o better documentation of Reason for Revocation 1145 o document user ID conventions 1147 16. Acknowledgements 1149 This document is the result of years of operational experience and 1150 observation, as well as conversations with many different people - 1151 users, implementors, keystore operators, etc. A non-exhaustive list 1152 of people who have contriubuted ideas or nuance to this document 1153 specifically includes: 1155 o Antoine Beaupre 1157 o Jamie McClelland 1159 o Jonathan McDowell 1161 o Justus Winter 1163 o Neal Walfield 1165 o vedaal 1167 o Vincent Breitmoser 1169 o Wiktor Kwapisiewicz 1171 17. References 1173 17.1. Normative References 1175 [I-D.ietf-openpgp-rfc4880bis] 1176 Koch, W., carlson, b., Tse, R., and D. Atkins, "OpenPGP 1177 Message Format", draft-ietf-openpgp-rfc4880bis-06 (work in 1178 progress), November 2018. 1180 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1181 Requirement Levels", BCP 14, RFC 2119, 1182 DOI 10.17487/RFC2119, March 1997, 1183 . 1185 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1186 Thayer, "OpenPGP Message Format", RFC 4880, 1187 DOI 10.17487/RFC4880, November 2007, 1188 . 1190 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1191 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1192 May 2017, . 1194 17.2. Informative References 1196 [DEBIAN-KEYRING] 1197 McDowell, J., "Debian Keyring", n.d., 1198 . 1200 [GnuPG] Koch, W., "Using the GNU Privacy Guard", n.d., 1201 . 1203 [I-D.koch-openpgp-webkey-service] 1204 Koch, W., "OpenPGP Web Key Directory", draft-koch-openpgp- 1205 webkey-service-07 (work in progress), November 2018. 1207 [I-D.shaw-openpgp-hkp] 1208 Shaw, D., "The OpenPGP HTTP Keyserver Protocol (HKP)", 1209 draft-shaw-openpgp-hkp-00 (work in progress), March 2003. 1211 [MAILVELOPE-KEYSERVER] 1212 Oberndoerfer, T., "Mailvelope Keyserver", n.d., 1213 . 1215 [MONKEYSPHERE] 1216 Gillmor, D. and J. Rollins, "Monkeysphere", n.d., 1217 . 1219 [PARCIMONIE] 1220 Intrigeri, ., "Parcimonie", n.d., 1221 . 1224 [PGP-GLOBAL-DIRECTORY] 1225 Symantec Corporation, "PGP Global Directory Key 1226 Verification Policy", 2011, 1227 . 1230 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1231 DOI 10.17487/RFC5322, October 2008, 1232 . 1234 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 1235 (DANE) Bindings for OpenPGP", RFC 7929, 1236 DOI 10.17487/RFC7929, August 2016, 1237 . 1239 [SKS] Pennock, P., "SKS Keyserver Documentation", March 2018, 1240 . 1243 [TOR] "The Tor Project", n.d., . 1245 Author's Address 1247 Daniel Kahn Gillmor 1248 American Civil Liberties Union 1249 125 Broad St. 1250 New York, NY 10004 1251 USA 1253 Email: dkg@fifthhorseman.net