idnits 2.17.00 (12 Aug 2021) /tmp/idnits58306/draft-dkg-openpgp-abuse-resistant-keystore-05.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1154 has weird spacing: '...ct (by remov...' == Line 1157 has weird spacing: '..., this remov...' == Line 1158 has weird spacing: '... any signat...' == Line 1159 has weird spacing: '...revoked signa...' -- The document date (28 April 2022) is 16 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Duplicate reference: RFC4880, mentioned in 'Attested-Certifications', was also mentioned in 'RFC4880'. == Outdated reference: A later version (-14) exists of draft-koch-openpgp-webkey-service-13 -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 openpgp D. K. Gillmor 3 Internet-Draft ACLU 4 Intended status: Informational 28 April 2022 5 Expires: 30 October 2022 7 Abuse-Resistant OpenPGP Keystores 8 draft-dkg-openpgp-abuse-resistant-keystore-05 10 Abstract 12 OpenPGP transferable public keys are composite certificates, made up 13 of primary keys, revocation signatures, direct key signatures, user 14 IDs, identity certifications ("signature packets"), subkeys, and so 15 on. They are often assembled by merging multiple certificates that 16 all share the same primary key, and are distributed in public 17 keystores. 19 Unfortunately, since many keystores permit any third-party to add a 20 certification with any content to any OpenPGP certificate, the 21 assembled/merged form of a certificate can become unwieldy or 22 undistributable. Furthermore, keystores that are searched by user ID 23 or fingerprint can be made unusable for specific searches by public 24 submission of bogus certificates. And finally, keystores open to 25 public submission can also face simple resource exhaustion from 26 flooding with bogus submissions, or legal or other risks from uploads 27 of toxic data. 29 This draft documents techniques that an archive of OpenPGP 30 certificates can use to mitigate the impact of these various attacks, 31 and the implications of these concerns and mitigations for the rest 32 of the OpenPGP ecosystem. 34 About This Document 36 This note is to be removed before publishing as an RFC. 38 The latest revision of this draft can be found at 39 https://dkg.gitlab.io/draft-openpgp-abuse-resistant-keystore/. 40 Status information for this document may be found at 41 https://datatracker.ietf.org/doc/draft-dkg-openpgp-abuse-resistant- 42 keystore/. 44 Discussion of this document takes place on the OpenPGP Working Group 45 mailing list (mailto:openpgp@ietf.org), which is archived at 46 https://mailarchive.ietf.org/arch/browse/openpgp/. 48 Source for this draft and an issue tracker can be found at 49 https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore. 51 Status of This Memo 53 This Internet-Draft is submitted in full conformance with the 54 provisions of BCP 78 and BCP 79. 56 Internet-Drafts are working documents of the Internet Engineering 57 Task Force (IETF). Note that other groups may also distribute 58 working documents as Internet-Drafts. The list of current Internet- 59 Drafts is at https://datatracker.ietf.org/drafts/current/. 61 Internet-Drafts are draft documents valid for a maximum of six months 62 and may be updated, replaced, or obsoleted by other documents at any 63 time. It is inappropriate to use Internet-Drafts as reference 64 material or to cite them other than as "work in progress." 66 This Internet-Draft will expire on 30 October 2022. 68 Copyright Notice 70 Copyright (c) 2022 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 75 license-info) in effect on the date of publication of this document. 76 Please review these documents carefully, as they describe your rights 77 and restrictions with respect to this document. Code Components 78 extracted from this document must include Revised BSD License text as 79 described in Section 4.e of the Trust Legal Provisions and are 80 provided without warranty as described in the Revised BSD License. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 85 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 86 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 87 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 88 2.1. Certificate Flooding . . . . . . . . . . . . . . . . . . 8 89 2.2. User ID Flooding . . . . . . . . . . . . . . . . . . . . 8 90 2.3. Fingerprint Flooding . . . . . . . . . . . . . . . . . . 9 91 2.4. Keystore Flooding . . . . . . . . . . . . . . . . . . . . 9 92 2.5. Toxic Data . . . . . . . . . . . . . . . . . . . . . . . 10 93 3. Keystore Interfaces . . . . . . . . . . . . . . . . . . . . . 10 94 3.1. Certificate Refresh . . . . . . . . . . . . . . . . . . . 10 95 3.2. Certificate Discovery . . . . . . . . . . . . . . . . . . 11 96 3.3. Certificate Lookup . . . . . . . . . . . . . . . . . . . 12 97 3.3.1. Full User ID Lookup . . . . . . . . . . . . . . . . . 12 98 3.3.2. E-mail Address Lookup . . . . . . . . . . . . . . . . 12 99 3.3.3. Other Lookup Mechanisms . . . . . . . . . . . . . . . 13 100 3.4. Certificate Validation . . . . . . . . . . . . . . . . . 13 101 3.5. Certificate Submission . . . . . . . . . . . . . . . . . 14 102 4. Simple Mitigations . . . . . . . . . . . . . . . . . . . . . 15 103 4.1. Decline Large Packets . . . . . . . . . . . . . . . . . . 15 104 4.2. Enforce Strict User IDs . . . . . . . . . . . . . . . . . 15 105 4.3. Scoped User IDs . . . . . . . . . . . . . . . . . . . . . 16 106 4.4. Strip or Standardize Unhashed Subpackets . . . . . . . . 16 107 4.4.1. Issuer Fingerprint . . . . . . . . . . . . . . . . . 16 108 4.4.2. Cross-sigs . . . . . . . . . . . . . . . . . . . . . 16 109 4.5. Decline User Attributes . . . . . . . . . . . . . . . . . 16 110 4.6. Decline Non-exportable Certifications . . . . . . . . . . 17 111 4.7. Decline Data From the Future . . . . . . . . . . . . . . 17 112 4.8. Accept Only Profiled Certifications . . . . . . . . . . . 17 113 4.9. Accept Only Certificates Issued by Designated 114 Authorities . . . . . . . . . . . . . . . . . . . . . . 17 115 4.10. Decline Packets by Blocklist . . . . . . . . . . . . . . 18 116 5. Retrieval-time Mitigations . . . . . . . . . . . . . . . . . 19 117 5.1. Redacting User IDs . . . . . . . . . . . . . . . . . . . 19 118 5.1.1. Certificate Refresh with Redacted User IDs . . . . . 19 119 5.1.2. Certificate Discovery with Redacted User IDs . . . . 20 120 5.1.3. Certificate Lookup with Redacted User IDs . . . . . . 20 121 5.1.4. Hinting Redacted User IDs . . . . . . . . . . . . . . 21 122 5.1.5. User ID Recovery by Client Brute Force . . . . . . . 21 123 5.2. Primary-key Only Certificate Refresh . . . . . . . . . . 21 124 5.3. Require Valid Cross-Sigs for Certificate Discovery . . . 22 125 6. Contextual Mitigations . . . . . . . . . . . . . . . . . . . 23 126 6.1. Accept Only Cryptographically-verifiable 127 Certifications . . . . . . . . . . . . . . . . . . . . . 23 128 6.2. Accept Only Certificates Issued by Known Certificates . . 23 129 6.3. Rate-limit Submissions by IP Address . . . . . . . . . . 24 130 6.4. Accept Certificates Based on Exterior Process . . . . . . 24 131 6.5. Accept Certificates by E-mail Validation . . . . . . . . 24 132 7. Non-append-only mitigations . . . . . . . . . . . . . . . . . 25 133 7.1. Drop Superseded Signatures . . . . . . . . . . . . . . . 25 134 7.2. Drop Expired Signatures . . . . . . . . . . . . . . . . . 26 135 7.3. Drop Dangling User IDs, User Attributes, and Subkeys . . 26 136 7.4. Drop All Other Elements of a Directly-Revoked 137 Certificate . . . . . . . . . . . . . . . . . . . . . . . 26 138 7.5. Implicit Expiration Date . . . . . . . . . . . . . . . . 27 139 8. Primary Key Sovereignty . . . . . . . . . . . . . . . . . . . 27 140 8.1. Refresh-only Keystores . . . . . . . . . . . . . . . . . 28 141 8.2. First-party-only Keystores . . . . . . . . . . . . . . . 29 142 8.2.1. First-party-only Without User IDs . . . . . . . . . . 29 143 8.3. First-party-attested Third-party Certifications . . . . . 29 144 8.3.1. Client Interactions . . . . . . . . . . . . . . . . . 30 145 8.3.2. Revoking Third-party Certifications . . . . . . . . . 30 146 9. Keystore Client Best Practices . . . . . . . . . . . . . . . 32 147 9.1. Use Constrained Keystores for Lookup . . . . . . . . . . 32 148 9.2. Normalize Addresses and User IDs for Lookup . . . . . . . 32 149 9.3. Avoid Fuzzy Lookups . . . . . . . . . . . . . . . . . . . 32 150 9.4. Prefer Full Fingerprint for Discovery and Refresh . . . . 33 151 9.5. Use Caution with Keystore-provided Validation . . . . . . 33 152 10. Certificate Generation and Management Best Practices . . . . 33 153 10.1. Canonicalized E-Mail Addresses . . . . . . . . . . . . . 34 154 10.2. Normalized User IDs . . . . . . . . . . . . . . . . . . 34 155 10.3. Avoid Large User Attributes . . . . . . . . . . . . . . 34 156 10.4. Provide Cross-Sigs . . . . . . . . . . . . . . . . . . . 34 157 10.5. Provide Issuer Fingerprint Subpackets . . . . . . . . . 35 158 10.6. Put Cross-Sigs and Issuer Fingerprint in Hashed 159 Subpackets . . . . . . . . . . . . . . . . . . . . . . . 35 160 10.7. Submit Certificates to Restricted, Lookup-Capable 161 Keystores . . . . . . . . . . . . . . . . . . . . . . . 35 162 11. Side Effects and Ecosystem Impacts . . . . . . . . . . . . . 35 163 11.1. Designated Revoker . . . . . . . . . . . . . . . . . . . 35 164 11.2. Key IDs vs. Fingerprints in Certificate Discovery . . . 36 165 11.3. In-band Certificates . . . . . . . . . . . . . . . . . . 36 166 11.3.1. In-band Certificate Minimization and Validity . . . 37 167 11.4. Certification-capable Subkeys . . . . . . . . . . . . . 38 168 11.5. Assessing Certificates in the Past . . . . . . . . . . . 38 169 11.5.1. Point-in-time Certificate Evaluation . . . . . . . . 39 170 11.5.2. Signature Verification and Non-append-only 171 Keystores . . . . . . . . . . . . . . . . . . . . . . 39 172 11.6. Global Append-only Ledgers ("Blockchain") . . . . . . . 39 173 11.7. Certificate Lookup for Identity Monitoring . . . . . . . 41 174 12. OpenPGP details . . . . . . . . . . . . . . . . . . . . . . . 41 175 12.1. Revocations . . . . . . . . . . . . . . . . . . . . . . 41 176 12.2. User ID Conventions . . . . . . . . . . . . . . . . . . 42 177 12.3. E-mail Address Canonicalization . . . . . . . . . . . . 43 178 12.3.1. Disallowing Non-UTF-8 Local Parts . . . . . . . . . 43 179 12.3.2. Domain Canonicalization . . . . . . . . . . . . . . 43 180 12.3.3. Local Part Canonicalization . . . . . . . . . . . . 43 181 13. Security Considerations . . . . . . . . . . . . . . . . . . . 43 182 13.1. Tension Between Unrestricted Uploads and Certificate 183 Lookup . . . . . . . . . . . . . . . . . . . . . . . . . 44 184 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 44 185 14.1. Publishing Identity Information . . . . . . . . . . . . 44 186 14.2. Social Graph . . . . . . . . . . . . . . . . . . . . . . 45 187 14.3. Tracking Clients by Queries . . . . . . . . . . . . . . 45 188 14.4. "Live" Certificate Validation Leaks Client Activity . . 46 189 14.5. Certificate Discovery Leaks Client Activity . . . . . . 46 190 14.6. Certificate Refresh Leaks Client Activity . . . . . . . 47 191 14.7. Distinct Keystore Interfaces Leak Client Context and 192 Intent . . . . . . . . . . . . . . . . . . . . . . . . . 47 193 14.8. Cleartext Queries . . . . . . . . . . . . . . . . . . . 48 194 14.9. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 48 195 15. User Considerations . . . . . . . . . . . . . . . . . . . . . 49 196 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 197 16.1. Document History . . . . . . . . . . . . . . . . . . . . 49 198 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 199 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 200 18.1. Normative References . . . . . . . . . . . . . . . . . . 52 201 18.2. Informative References . . . . . . . . . . . . . . . . . 53 202 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 55 204 1. Introduction 206 1.1. Requirements Language 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 210 "OPTIONAL" in this document are to be interpreted as described in BCP 211 14 [RFC2119] [RFC8174] when, and only when, they appear in all 212 capitals, as shown here. 214 1.2. Terminology 216 * "OpenPGP certificate" (or just "certificate") is used 217 interchangeably with [RFC4880]'s "Transferable Public Key". The 218 term "certificate" refers unambiguously to the entire composite 219 object, unlike "key", which might also be used to refer to a 220 primary key or subkey. 222 * An "identity certification" (or just "certification") is an 223 [RFC4880] signature packet that covers OpenPGP identity 224 information -- that is, any signature packet of type 0x10, 0x11, 225 0x12, or 0x13. Certifications are said to (try to) "bind" a 226 primary key to a User ID. 228 * The primary key that makes the certification is known as the 229 "issuer". The primary key over which the certification is made is 230 known as the "subject". 232 * A "first-party certification" is issued by the primary key of a 233 certificate, and binds itself to a user ID in the certificate. 234 That is, the issuer is the same as the subject. This is sometimes 235 referred to as a "self-sig". 237 * A "third-party certification" is a made over a primary key and 238 user ID by some other certification-capable primary key. That is, 239 the issuer is different than the subject. The elusive "second- 240 party" is presumed to be the verifier who is trying to interpret 241 the certificate. 243 * All subkeys are bound to the primary key with an [RFC4880] Subkey 244 Binding Signature. Some subkeys also reciprocate by binding 245 themselves back to the primary key with an [RFC4880] Primary Key 246 Binding Signature. The Primary Key Binding Signature is also 247 known as a "cross-signature" or "cross-sig". 249 * A "keystore" is any collection of OpenPGP certificates. Keystores 250 typically receive mergeable updates over the course of their 251 lifetime which might add to the set of OpenPGP certificates they 252 hold, or update the certificates. 254 * "Certificate validation" is the process whereby a user decides 255 whether a given user ID in an OpenPGP certificate is acceptable 256 for use. For example, if the certificate has a user ID of Alice 257 and the user wants to send an e-mail to 258 alice@example.org, the mail user agent might want to ensure that 259 the certificate is valid for this e-mail address before encrypting 260 to it. Some clients may rely on specific keystores for 261 certificate validation, but some keystores (e.g., [SKS]) make no 262 assertions whatsoever about certificate validity, and others offer 263 only very subtle guarantees. See Section 3.4 for more details. 265 * "Certificate lookup" refers to the retrieval of a set of 266 certificates from a keystore based on the user ID or some 267 substring match of the user ID. See Section 3.3 for more details. 269 * "Certificate refresh" refers to retrieval of a certificate from a 270 keystore based on the fingerprint of the primary key. See 271 Section 3.1 for more details. 273 * "Certificate discovery" refers to the retrieval of a set of 274 certificates from a keystore based on the fingerprint or key ID of 275 any key in the certificate. See Section 3.2 for more details. 277 * A "keyserver" is a particular kind of keystore, typically a means 278 of publicly distributing OpenPGP certificates or updates to them. 279 Examples of keyserver software include [SKS] and 280 [MAILVELOPE-KEYSERVER]. One common HTTP interface for keyservers 281 is [I-D.shaw-openpgp-hkp]. 283 * A "synchronizing keyserver" is a keyserver which gossips with 284 other peers, and typically acts as an append-only log. Such a 285 keyserver is typically useful for certificate lookup, certificate 286 discovery, and certificate refresh (including revocation 287 information). They are typically _not_ useful for certificate 288 validation, since they make no assertions about whether the 289 identities in the certificates they server are accurate. As of 290 the writing of this document, [SKS] is the canonical synchronizing 291 keyserver implementation, though other implementations exist. 293 * An "e-mail validating keyserver" is a keyserver which attempts to 294 verify the identity in an OpenPGP certificate's user ID by 295 confirming access to the e-mail account, and optionally by 296 confirming access to the secret key. Some implementations permit 297 removal of a certificate by anyone who can prove access to the 298 e-mail address in question. They are useful for certificate 299 lookup based on e-mail address and certificate validation (by 300 users who trust the operator), but some may not be useful for 301 certificate refresh or certificate discovery, since a certificate 302 could be simply replaced by an adversary who also has access to 303 the e-mail address in question. [MAILVELOPE-KEYSERVER] is an 304 example of such a keyserver. 306 * A "sovereignty-respecting" keystore is one that only distributes 307 data associated with a given certificate that has been explicitly 308 approved by the primary key of that certificate. See Section 8 309 for more details and example strategies. 311 * "Cryptographic validity" refers to mathematical evidence that a 312 signature came from the secret key associated with the public key 313 it claims to come from. Note that a certification may be 314 cryptographically valid without the signed data being true (for 315 example, a given certificate with the user ID Alice 316 might not belong to the person who controls 317 the e-mail address alice@example.org even though the self-sig is 318 cryptographically valid). In particular, cryptographic validity 319 for user ID in a certificate is typically insufficient evidence 320 for certificate validation. Also note that knowledge of the 321 public key of the issuer is necessary to determine whether any 322 given signature is cryptographically valid. Some keyservers 323 perform cryptographic validation in some contexts. Other 324 keyservers (like [SKS]) perform no cryptographic validation 325 whatsoever. 327 * OpenPGP revocations can have "Reason for Revocation" (see 328 [RFC4880]), which can be either "soft" or "hard". The set of 329 "soft" reasons is: "Key is superseded" and "Key is retired and no 330 longer used". All other reasons (and revocations that do not 331 state a reason) are "hard" revocations. See Section 12.1 for more 332 detail. 334 2. Problem Statement 336 OpenPGP keystores that handle submissions from the public are subject 337 to a range of attacks by malicious submitters. 339 This section describes five distinct attacks that public keystores 340 should consider. 342 2.1. Certificate Flooding 344 Many public keystores (including both the [SKS] keyserver network and 345 [MAILVELOPE-KEYSERVER]) allow anyone to attach arbitrary data (in the 346 form of third-party certifications) to any certificate, bloating that 347 certificate to the point of being impossible to effectively retrieve. 348 For example, some OpenPGP implementations simply refuse to process 349 certificates larger than a certain size. 351 This kind of Denial-of-Service attack makes it possible to make 352 someone else's certificate unretrievable from the keystore, 353 preventing certificate lookup, discovery, or refresh. In the case of 354 a revoked certificate that has been flooded, this potentially leaves 355 the client of the keystore with the compromised certificate in an 356 unrevoked state locally because it was unable to fetch the revocation 357 information. 359 Additionally, even without malice, OpenPGP certificates can 360 potentially grow without bound. 362 2.2. User ID Flooding 364 Public keystores that are used for certificate lookup may also be 365 vulnerable to attacks that flood the space of known user IDs. In 366 particular, if the keystore accepts arbitrary certificates from the 367 public and does no verification of the user IDs, then any client 368 searching for a given user ID may need to review and process an 369 effectively unbounded set of maliciously-submitted certificates to 370 find the non-malicious certificates they are looking for. 372 For example, if an attacker knows that a given system consults a 373 keystore looking for certificates which match the e-mail address 374 alice@example.org, the attacker may upload thousands of certificates 375 containing user IDs that match that address. Even if those 376 certificates would not be accepted by a client (e.g., because they 377 were not certified by a known-good authority), the client still has 378 to iterate through all of them in order to find the non-malicious 379 certificates. 381 User ID flooding is only effective if the keystore offers a lookup 382 interface at all. 384 2.3. Fingerprint Flooding 386 A malicious actor who wants to render a certificate unavailable for 387 refresh may generate an arbitrary number of OpenPGP certificates with 388 the targeted primary key attached as a subkey. If they can convince 389 a keystore to accept all of those certificates, and the keystore 390 returns them by subkey match during certificate refresh, then the 391 certificate refresh client will need to spend an arbitrary amount of 392 bandwidth and processing power filtering out the irrelevant data, and 393 may potentially give up before discovering the certificate of 394 interest. 396 A malicious actor may also want to confuse a certificate discovery 397 request that was targeted at a particular subkey, by binding that 398 subkey to multiple bogus certificates. If these bogus certificates 399 are ingested and redistributed by the keystore, then a certificate 400 discovery client may receive a set of certificates that cannot be 401 adequately distinguished. 403 2.4. Keystore Flooding 405 A public keystore that accepts arbitrary OpenPGP material and is 406 append-only is at risk of being overwhelmed by sheer quantity of 407 malicious uploaded packets. This is a risk even if the user ID space 408 is not being deliberately flooded, and if individual certificates are 409 protected from flooding by any of the mechanisms described later in 410 this document. 412 The keystore itself can become difficult to operate if the total 413 quantity of data is too large, and if it is a synchronizing 414 keyserver, then the quantities of data may impose unsustainable 415 bandwidth costs on the operator as well. 417 Effectively mitigating against keystore flooding requires either 418 abandoning the append-only property that some keystores prefer, or 419 imposing very strict controls on initial ingestion. 421 2.5. Toxic Data 423 Like any large public dataset, it's possible that a keystore ends up 424 hosting some content that is legally actionable in some 425 jurisdictions, including libel, child pornography, material under 426 copyright or other "intellectual property" controls, blasphemy, hate 427 speech, etc. 429 A public keystore that accepts and redistributes arbitrary content 430 may face risk due to uploads of toxic data. 432 3. Keystore Interfaces 434 Some keystores have simple interfaces, like files present in a local 435 filesystem. But many keystores offer an API for certificate 436 retrieval of different types. This section documents a set of useful 437 interactions that a client may have with such a keystore. 439 They are represented in abstract form, and are not intended to be the 440 full set of interfaces offered by any keystore, but rather a 441 convenient way to think about the operations that make the keystore 442 useful for its clients. 444 Not all keystores may offer all of these interfaces, or they may 445 offer them in subtly different forms, but clients will nevertheless 446 try to perform something like these operations with keystores that 447 they interact with. 449 3.1. Certificate Refresh 451 This is the simplest keystore operation. The client sends the 452 keystore the full fingerprint of the certificate's primary key, and 453 the keystore sends the client the corresponding certificate (or 454 nothing, if the keystore does not contain a certificate with a 455 matching primary key). 457 keystore.cert_refresh(primary_fpr) -> certificate? 459 A client uses certificate refresh to retrieve the full details of a 460 certificate that it already knows about. For example, it might be 461 interested in refreshs to the certificate known to the keystore, 462 including revocations, expiration refreshs, new third-party 463 certifications, etc. 465 Upon successful refresh, the client SHOULD merge the retrieved 466 certificate with its local copy. 468 Not all keystores offer this operation. For example, clients cannot 469 use WKD ([I-D.koch-openpgp-webkey-service]) or OPENPGPKEY ([RFC7929]) 470 for certificate refresh. 472 3.2. Certificate Discovery 474 If a client is aware of an OpenPGP signature or certification that it 475 cannot verify because it does not know the issuing certificate, it 476 may consult a keystore to try to discover the certificate based on 477 the Issuer or Issuer Fingerprint subpacket in the signature or 478 certification it is trying to validate. 480 keystore.cert_discovery(keyid|fpr) -> certificate_list 482 This is subtly different from certificate refresh (Section 3.1) in 483 three ways: 485 * it may return more than one certificate (e.g., when multiple 486 certificates share a subkey, or when a primary key on one 487 certificate is a subkey on another) 489 * it is willing to accept searches by short key ID, not just 490 fingerprint 492 * it is willing to match against a subkey, not just a primary key 494 While a certificate discovery client does not initially know the 495 certificate it is looking for, it's possible that the returned 496 certificate is one that the client already knows about. For example, 497 a new subkey may have been added to a certificate. 499 Upon successful discovery, the client SHOULD merge any retrieved 500 certificates with discovered local copies (as determined by primary 501 key), and then evaluate the original signature against any retrieved 502 certificate that appears to be valid and reasonable for use in the 503 signing context. 505 It is unclear what a client should do if multiple certificates do 506 appear to be valid for a given signature, because of ambiguity this 507 represents about the identity of the signer. However, this ambiguity 508 is similar to the ambiguity of a certificate with multiple valid user 509 IDs, which the client already needs to deal with. 511 Not all keystores offer this operation. For example, clients cannot 512 use WKD ([I-D.koch-openpgp-webkey-service]) or OPENPGPKEY ([RFC7929] 513 for certificate discovery. 515 3.3. Certificate Lookup 517 If a client wants to encrypt a message to a particular e-mail 518 address, or wants to encrypt a backup to some identity that it knows 519 of but does not have a certificate for, it may consult a keystore to 520 discover certificates that claim that identity in their user ID 521 packets. Both [I-D.koch-openpgp-webkey-service] and 522 [I-D.shaw-openpgp-hkp] offer certificate lookup mechanisms. 524 [RFC4880] User IDs are constrained only in that they are a UTF-8 525 string, but some conventions govern their practical use. See 526 Section 12.2 for more discussion of some common conventions around 527 user ID structure. 529 Note that lookup does not necessarily imply user ID or certificate 530 validation. It is entirely possible for a keystore to return a 531 certificate during lookup that the client cannot validate. 533 Abuse-resistant keystores that offer a lookup interface SHOULD 534 distinguish interfaces that perform full-string-match lookup from 535 interfaces that perform e-mail address based lookup. 537 3.3.1. Full User ID Lookup 539 The most straightforward form of certificate lookup asks for the set 540 of all certificates that contain a user ID that exactly and 541 completely matches the query parameter supplied by the client. 543 keystore.cert_lookup(uid) -> certificate_list 545 In its simplest form, this match is done by a simple bytestring 546 comparison. More sophisticated keystores MAY perform the comparison 547 after applying [UNICODE-NORMALIZATION] form NFC to both the uid query 548 and the user IDs from the stored certificates. 550 3.3.2. E-mail Address Lookup 552 However, some common use cases look for specific patterns in the user 553 ID rather than the entire user ID. Most useful to many existing 554 OpenPGP clients is a lookup by e-mail address. 556 keystore.cert_lookup(addr) -> certificate_list 558 For certificates with a user ID that matches the structure of an 559 [RFC5322] name-addr or addr-spec, a keystore SHOULD extract the addr- 560 spec from the user ID, canonicalize it (see Section 12.3), and 561 compare it to the canonicalized form of of the addr query parameter. 563 3.3.3. Other Lookup Mechanisms 565 Some keystores offer other forms of substring or regular expression 566 matching against the stored user IDs. These other forms of lookup 567 may be useful in some contexts (e.g., Section 11.7), but they may 568 also represent privacy concerns (e.g., Section 14.1), and they may 569 impose additional computational or indexing burdens on the keystore. 571 3.4. Certificate Validation 573 An OpenPGP client may assess certificate and user ID validity based 574 on many factors, some of which are directly contained in the 575 certificate itself (e.g., third-party certifications), and some of 576 which are based on the context known to the client, including: 578 * Whether it has seen e-mails from that address signed by that 579 certificate in the past, 581 * How long it has known about the certificate, 583 * Whether the certificate was fetched from a keystore that asserts 584 validity of the user ID or some part of it (such as the e-mail 585 address). 587 A keystore MAY facilitate clients pursuing this last point of 588 contextual corroboration via a direct interface: 590 keystore.cert_validate(primary_fpr, uid) -> boolean 592 In an e-mail-specific context, the client might only care about the 593 keystore's opinion about the validity of the certificate for the 594 e-mail address portion of the user ID only: 596 keystore.cert_validate(primary_fpr, addr) -> boolean 598 For some keystores, the presence of a certificate in the keystore 599 alone implies that the keystore asserts the validity of all user IDs 600 in the certificate retrieved. For others, the presence in the 601 keystore applies only to some part of the user ID. For example, 602 [PGP-GLOBAL-DIRECTORY] will only return user IDs that have completed 603 an e-mail validation step, so presence in that keystore implies an 604 assertion of validity of the e-mail address part of the user IDs 605 returned, but makes no claim about the display-name portion of any 606 returned user IDs. Note that a client retrieving a certificate from 607 such a keystore may merge the certificate with a local copy -- but 608 the validity asserted by the keystore of course has no bearing on the 609 packets that the keystore did not return. 611 In a more subtle example, the retrieval of a certificate looked up 612 via WKD ([I-D.koch-openpgp-webkey-service]) or DANE ([RFC7929]) 613 should only be interpreted as a claim of validity about any user ID 614 which matches the e-mail address by which the certificate was looked 615 up, with no claims made about any display-name portions, or about any 616 user ID that doesn't match the queried e-mail address at all. 618 A keystore that offers some sort of validation interface may also 619 change its opinion about the validity of a given certificate or user 620 ID over time; the interface described above only allows the client to 621 ask about the keystore's current opinion, but a more complex 622 interface might be capable of describing the keystore's assertion 623 over time. See also Section 11.5. 625 An abuse-resistant keystore that clients rely on for any part of 626 their certificate validation process SHOULD offer a distinct 627 interface for making assertions about certificate and user ID 628 validity to help clients avoid some of the subtleties involved with 629 inference based on presence described above. 631 Note that the certificate validation operation as described above has 632 a boolean response. While a "true" response indicates that keystore 633 believes the user ID or e-mail address is acceptable for use with the 634 certificate referred to by the public key fingerprint, a "false" 635 response doesn't necessarily mean that the keystore actively thinks 636 that the certificate is actively bad, or must not be used for the 637 referenced identity. Rather, "false" is the default state: no 638 opinion is expressed by the keystore, and the client is left to make 639 their own inference about validity based on other factors. A 640 keystore MAY offer a more nuanced validity interface; if it does, it 641 SHOULD explicitly document the semantics of the different response 642 types so that clients can make appropriate judgment. 644 3.5. Certificate Submission 646 Different keystores have different ways to submit a certificate for 647 consideration for ingestion, including: 649 * a simple upload of a certificate via HTTP 651 * round-trip e-mail verification 653 * proof of presence in some other service 655 * vouching, or other forms of multi-party attestation 656 Because these schemes vary so widely, this document does not attempt 657 to describe the keystore certificate submission process in detail. 658 However, guidance can be found for implementations that generate, 659 manage, and submit certificates in Section 10. 661 4. Simple Mitigations 663 These steps can be taken by any keystore that wants to avoid 664 obviously malicious abuse. They can be implemented on receipt of any 665 new packet, and are based strictly on the structure of the packet 666 itself. 668 4.1. Decline Large Packets 670 While [RFC4880] permits OpenPGP packet sizes of arbitrary length, 671 OpenPGP certificates rarely need to be so large. An abuse-resistant 672 keystore SHOULD reject any OpenPGP packet larger than 8383 octets. 673 (This cutoff is chosen because it guarantees that the packet size can 674 be represented as a one- or two-octet [RFC4880] "New Format Packet 675 Length", but it could be reduced further) 677 This may cause problems for user attribute packets that contain large 678 images, but it's not clear that these images are concretely useful in 679 any context. Some keystores MAY extend this limit for user attribute 680 packets specifically, but SHOULD NOT allow even user attributes 681 packets larger than 65536 octets. 683 4.2. Enforce Strict User IDs 685 [RFC4880] indicates that User IDs are expected to be UTF-8 strings. 686 An abuse-resistant keystore MUST reject any user ID that is not valid 687 UTF-8. 689 Some abuse-resistant keystores MAY only accept User IDs that meet 690 even stricter conventions, such as an [RFC5322] name-addr or addr- 691 spec, or a URL like ssh://host.example.org (see Section 12.2). 693 As simple text strings, User IDs don't need to be nearly as long as 694 any other packets. An abuse-resistant keystore SHOULD reject any 695 user ID packet larger than 1024 octets. 697 4.3. Scoped User IDs 699 Some abuse-resistant keystores may restrict themselves to publishing 700 only certificates with User IDs that match a specific pattern. For 701 example, [RFC7929] encourages publication in the DNS of only 702 certificates whose user IDs refer to e-mail addresses within the DNS 703 zone. [I-D.koch-openpgp-webkey-service] similarly aims to restrict 704 publication to certificates relevant to the specific e-mail domain. 706 4.4. Strip or Standardize Unhashed Subpackets 708 [RFC4880] signature packets contain an "unhashed" block of 709 subpackets. These subpackets are not covered by any cryptographic 710 signature, so they are ripe for abuse. 712 An abuse-resistant keystore SHOULD strip out all unhashed subpackets 713 but the following exceptions: 715 4.4.1. Issuer Fingerprint 717 Some certifications only identify the issuer of the certification by 718 an unhashed Issuer or Issuer Fingerprint subpacket. If a 719 certification's hashed subpacket section has no Issuer Fingerprint 720 (see [I-D.ietf-openpgp-rfc4880bis]) subpacket, then an abuse- 721 resistant keystore that has cryptographically validated the 722 certification SHOULD synthesize an appropriate Issuer Fingerprint 723 subpacket and include it in the certification's unhashed subpackets. 725 4.4.2. Cross-sigs 727 Some Primary Key Binding Signatures ("cross-sigs") are distributed as 728 unhashed subpackets in a Subkey Binding Signature. A 729 cryptographically-validating abuse-resistant keystore SHOULD be 730 willing to redistribute a valid cross-sig as an unhashed subpacket. 732 The redistributed unhashed cross-sig itself should be stripped of all 733 unhashed subpackets. 735 4.5. Decline User Attributes 737 Due to size concerns, some abuse-resistant keystores MAY choose to 738 ignore user attribute packets entirely, as well as any certifications 739 that cover them. 741 4.6. Decline Non-exportable Certifications 743 An abuse-resistant keystore MUST NOT accept any certification that 744 has the "Exportable Certification" subpacket present and set to 0. 745 While most keystore clients will not upload these "local" 746 certifications anyway, a reasonable public keystore that wants to 747 minimize data has no business storing or distributing these 748 certifications. 750 4.7. Decline Data From the Future 752 Many OpenPGP packets have time-of-creation timestamps in them. An 753 abuse-resistant keystore with a functional real-time clock MAY decide 754 to only accept packets whose time-of-creation is in the past. 756 Note that some OpenPGP implementations may pre-generate OpenPGP 757 material intended for use only in some future window (e.g. "Here is 758 the certificate we plan to use to sign our software next year; do not 759 accept signatures from it until then."), and may use modified time- 760 of-creation timestamps to try to achieve that purpose. This material 761 would not be distributable ahead of time by an abuse-resistant 762 keystore that adopts this mitigation. 764 4.8. Accept Only Profiled Certifications 766 An aggressively abuse-resistant keystore MAY decide to only accept 767 certifications that meet a specific profile. For example, it MAY 768 reject certifications with unknown subpacket types, unknown 769 notations, or certain combinations of subpackets. This can help to 770 minimize the amount of room for garbage data uploads. 772 Any abuse-resistant keystore that adopts such a strict posture should 773 clearly document what its expected certificate profile is, and should 774 have a plan for how to extend the profile if new types of 775 certification appear that it wants to be able to distribute. 777 Note that if the profile is ever restricted (rather than extended), 778 and the restriction is applied to the material already present, such 779 a keystore is no longer append-only (see Section 7). 781 4.9. Accept Only Certificates Issued by Designated Authorities 783 An abuse-resistant keystore capable of cryptographic validation MAY 784 retain a list of designated authorities, typically in the form of a 785 set of known public keys. Upon receipt of a new OpenPGP certificate, 786 the keystore can decide whether to accept or decline each user ID of 787 the certificate based whether that user ID has a certification that 788 was issued by one or more of the designated authorities. 790 If no user IDs are certified by designated authority, such a keystore 791 SHOULD decline the certificate and its primary key entirely. Such a 792 keystore SHOULD decline to retain or propagate all certifications 793 associated with each accepted user ID except for first-party 794 certifications and certifications by the designated authorities. 796 The operator of such a keystore SHOULD have a clear policy about its 797 set of designated authorities. 799 Given the ambiguities about expiration and revocation, such a 800 keyserver SHOULD ignore expiration and revocation of authority 801 certifications, and simply accept and retain as long as the 802 cryptographic signature is valid. 804 Note that if any key is removed from the set of designated 805 authorities, and that change is applied to the existing keystore, 806 such a keystore may no longer be append-only (see Section 7). 808 4.10. Decline Packets by Blocklist 810 The maintainer of the keystore may keep a specific list of "known- 811 bad" material, and decline to accept or redistribute items matching 812 that blocklist. The material so identified could be anything, but 813 most usefully, specific public keys or User IDs could be blocked. 815 Note that if a blocklist grows to include an element already present 816 in the keystore, it will no longer be append-only (see Section 7). 818 Some keystores may choose to apply a blocklist only at retrieval time 819 and not apply it at ingestion time. This allows the keystore to be 820 append-only, and permits synchronization between keystores that don't 821 share a blocklist, and somewhat reduces the attacker's incentive for 822 flooding the keystore (see Section 5 for more discussion). 824 Note that development and maintenance of a blocklist is not without 825 its own potentials for abuse. For one thing, the blocklist may 826 itself grow without bound. Additionally, a blocklist may be socially 827 or politically contentious as it may describe data that is toxic 828 (Section 2.5) in one community or jurisdiction but not another. 829 There needs to be a clear policy about how it is managed, whether by 830 delegation to specific decision-makers, or explicit tests. 831 Furthermore, the existence of even a well-intentioned blocklist may 832 be an "attractive nuisance," drawing the interest of would-be censors 833 or other attacker interested in controlling the ecosystem reliant on 834 the keystore in question. 836 5. Retrieval-time Mitigations 838 Most of the abuse mitigations described in this document are 839 described as being applied at certificate ingestion time. It's also 840 possible to apply the same mitigations when a certificate is 841 retrieved from the keystore (that is, during certificate lookup, 842 refresh, or discovery). Applying an abuse mitigation at retrieval 843 time may help a client defend against a user ID flooding 844 (Section 2.2), certificate flooding (Section 2.1), or fingerprint 845 flooding (Section 2.3) attack. It may also help a keystore limit its 846 liability for redistributing toxic data (Section 2.5). However, only 847 mitigations applied at ingestion time are able to mitigate keystore 848 flooding attacks (Section 2.4). 850 Some mitigations (like the non-append-only mitigations described in 851 Section 7) may be applied as filters at retrieval time, while still 852 allowing access to the (potentially much larger) unfiltered dataset 853 associated given certificate or user ID via a distinct interface. 855 The rest of this section documents specific mitigations that are only 856 relevant at retrieval time (certificate discovery, lookup, or 857 refresh). 859 5.1. Redacting User IDs 861 Some abuse-resistant keystores may accept and store user IDs but 862 decline to redistribute some or all of them, while still distributing 863 the certifications that cover those redacted user IDs. This draft 864 refers to such a keystore as a "user ID redacting" keystore. 866 The certificates distributed by such a keystore are technically 867 invalid [RFC4880] "transferable public keys", because they lack a 868 user ID packet, and the distributed certifications cannot be 869 cryptographically validated independently. However, an OpenPGP 870 implementation that already knows the user IDs associated with a 871 given primary key will be capable of associating each certification 872 with the correct user ID by trial signature verification. 874 5.1.1. Certificate Refresh with Redacted User IDs 876 A user ID redacting keystore is useful for certificate refresh by a 877 client that already knows the user ID it expects to see associated 878 with the certificate. For example, a client that knows a given 879 certificate currently has two specific user IDs could access the 880 keystore to learn that one of the user IDs has been revoked, without 881 any other client learning the user IDs directly from the keystore. 883 5.1.2. Certificate Discovery with Redacted User IDs 885 A user ID redacting keystore is somewhat less useful for clients 886 doing certificate discovery. Consider the circumstance of receiving 887 a signed e-mail without access to the signing certificate. If the 888 verifier retrieves the certificate from a user ID redacting keystore 889 by via the Issuer Fingerprint from the signature, and the signature 890 validates, the received certificate might not be a valid 891 "transferable public key" unless the client can synthesize the proper 892 user ID. 894 A reasonable client that wants to validate a certification in the 895 user ID redacted certificate SHOULD try to synthesize possible user 896 IDs based on the value of the [RFC5322] From: header in the message: 898 * Decode any [RFC2047] encodings present in the raw header value, 899 converting into UTF-8 [UNICODE-NORMALIZATION] form C (NFC), 900 trimming all whitespace from the beginning and the end of the 901 string. 903 * The resulting string should be an [RFC5322] name-addr or addr- 904 spec. 906 * If it is a name-addr, convert the UTF-8 string into an OpenPGP 907 user ID and check whether the certification validates, terminating 908 on success. 910 - If the test fails, extract the addr-spec from the name-addr and 911 continue. 913 * Canonicalize the addr-spec according to Section 12.3, and check 914 whether the certification validates, terminating on success. 916 * If it doesn't validate wrap the canonicalized addr-spec in angle- 917 brackets ("<" and ">") and test the resulting minimalist name-addr 918 against the certification, terminating on success. 920 * If all of the above fails, synthesis has failed. 922 5.1.3. Certificate Lookup with Redacted User IDs 924 It's possible (though non-intuitive) to use a user ID redacting 925 keystore for certificate lookup. Since the keystore retains (but 926 does not distribute) the user IDs, they can be used to select 927 certificates in response to a search. The OpenPGP certificates sent 928 back in response to the search will not contain the user IDs, but a 929 client that knows the full user ID they are searching for will be 930 able to verify the returned certifications. 932 Certificate lookup from a user ID redacting keystore works better for 933 certificate lookup by exact user ID match than it does for substring 934 match, because a client that retrieves a certificate via a substring 935 match may not be able to reconstruct the redacted user ID. 937 However, without some additional restrictions on which certifications 938 are redistributed (whether the user ID is redacted or not), 939 certificate lookup can be flooded (see Section 13.1). 941 5.1.4. Hinting Redacted User IDs 943 To ensure that the distributed certificate is at least structurally a 944 valid [RFC4880] transferable public key, a user ID redacting keystore 945 MAY distribute an empty user ID (an OpenPGP packet of tag 13 whose 946 contents are a zero-octet string) in place of the omitted user ID. 947 This two-octet replacement user ID packet ("\xb4\x00") is called the 948 "unstated user ID". 950 To facilitate clients that match certifications with specific user 951 IDs, a user ID redacting keystore MAY insert a non-hashed notation 952 subpacket into the certification. The notation will have a name of 953 "uidhash", with 0x80 ("human-readable") flag unset. The value of 954 such a notation MUST be 32 octets long, and contains the SHA-256 955 cryptographic digest of the UTF-8 string of the redacted user ID. 957 A certificate refresh client which receives such a certification 958 after the "unstated user ID" SHOULD compute the SHA-256 digest of all 959 user IDs it knows about on the certificate, and compare the result 960 with the contents of the "uidhash" notation to decide which user ID 961 to try to validate the certification against. 963 5.1.5. User ID Recovery by Client Brute Force 965 User ID redaction is at best an imperfect process. Even if a 966 keystore redacts a User ID, if it ships a certification over that 967 user ID, an interested client can guess user IDs until it finds one 968 that causes the signature to verify. This is even easier when the 969 space of legitimate user IDs is relatively small, such as the set of 970 commonly-used hostnames. 972 5.2. Primary-key Only Certificate Refresh 974 Abuse-resistant keystores can defend against a fingerprint flooding 975 Section 2.3 attack during certificate refresh by implementing a 976 narrowly-constrained certificate refresh interface. 978 Such a keystore MUST accept only a full fingerprint as the search 979 parameter from the certificate refresh client, and it MUST return at 980 most a single certificate whose primary key matches the requested 981 fingerprint. It MUST NOT return more than one certificate, and it 982 MUST NOT return any certificate whose primary key does not match the 983 fingerprint. In particular, it MUST NOT return certificates where 984 only the subkey fingerprint matches. 986 Note that [I-D.shaw-openpgp-hkp] does not offer the primitive 987 described in Section 3.1 exactly. In that specification, the set of 988 keys returned by a "get" operation with a "search" parameter that 989 appears to be a full fingerprint is ambiguous. Some popular 990 implementations (e.g., [SKS]) do not currently implement this 991 mitigation, because they return certificates with subkeys that match 992 the fingerprint. 994 5.3. Require Valid Cross-Sigs for Certificate Discovery 996 By definition, certificate discovery needs to be able to match 997 subkeys, not just primary keys. This means that the mitigation in 998 Section 5.2 is ineffective for a keystore that offers a certificate 999 discovery interface. 1001 An abuse-resistant keystore that aims to defend its certificate 1002 discovery interface from a fingerprint flooding (Section 2.3) attack 1003 can follow the following procedure. 1005 Such a keystore MUST accept only a full fingerprint or a 64-bit key 1006 ID as the search parameter from the certificate discovery client. It 1007 MUST only match that fingerprint against the following: 1009 * the fingerprint or key ID of a primary key associated with a valid 1010 certificate 1012 * the fingerprint or key ID of a cryptographically-valid subkey that 1013 also has a cross-sig. 1015 This defends against the fingerprint flooding attack because a 1016 certificate will only be returned by subkey if the subkey has agreed 1017 to be associated with the primary key (and vice versa). 1019 Note that this mitigation means that certificate discovery will fail 1020 if used for subkeys that lack cross-sigs. In particular, this means 1021 that a client that tries to use the certificate discovery interface 1022 to retrieve a certificate based on its encryption-capable subkey 1023 (e.g., taking the key ID from a Public Key Encrypted Session Key 1024 (PKESK) packet) will have no success. 1026 This is an acceptable loss, since the key ID in a PKESK is typically 1027 unverifiable anyway. 1029 6. Contextual Mitigations 1031 Some mitigations make the acceptance or rejection of packets 1032 contingent on data that is already in the keystore or the keystore's 1033 developing knowledge about the world. This means that, depending on 1034 the order that the keystore encounters the various material, or how 1035 it accesses or finds the material, the final set of material retained 1036 and distributed by the keystore might be different. 1038 While this isn't necessarily bad, it may be a surprising property for 1039 some users of keystores. 1041 6.1. Accept Only Cryptographically-verifiable Certifications 1043 An abuse-resistant keystore that is capable of doing cryptographic 1044 validation MAY decide to reject certifications that it cannot 1045 cryptographically validate. 1047 This may mean that the keystore rejects some packets while it is 1048 unaware of the public key of the issuer of the packet. 1050 As long as the keystore implements the verification algorithm, Any 1051 self-signature should always be cryptographically-verifiable, since 1052 the public key of the issuer is already present in the certificate 1053 under consideration. 1055 6.2. Accept Only Certificates Issued by Known Certificates 1057 This is an extension of Section 4.9, but where the set of authorities 1058 is just the set of certificates already known to the keystore. An 1059 abuse-resistant keystore that adopts this strategy is effectively 1060 only crawling the reachable graph of OpenPGP certificates from some 1061 starting core. 1063 A keystore adopting the mitigation SHOULD have a clear documentation 1064 of the core of initial certificates it starts with, as this is 1065 effectively a policy decision. 1067 This mitigation measure may fail due to a compromise of any secret 1068 key that is associated with a primary key of a certificate already 1069 present in the keystore. Such a compromise permits an attacker to 1070 flood the rest of the network. In the event that such a compromised 1071 key is identified, it might be placed on a blocklist (see 1072 Section 4.10). In particular, if a public key is added to a 1073 blocklist for a keystore implementing this mitigation, and it is 1074 removed from the keystore, then all certificates that were only 1075 "reachable" from the blocklisted certificate should also be 1076 simultaneously removed. 1078 FIXME: There are complexities associated with this strategy when 1079 certificates expire or are revoked. If expiration or revocation 1080 cause some certificates to become "unreachable", what should such a 1081 keystore do? 1083 6.3. Rate-limit Submissions by IP Address 1085 Some OpenPGP keystores accept material from the general public over 1086 the Internet. If an abuse-resistant keystore observes a flood of 1087 material submitted to the keystore from a given Internet address, it 1088 MAY choose to throttle submissions from that address. When receiving 1089 submissions over IPv6, such a keystore MAY choose to throttle entire 1090 nearby subnets, as a malicious IPv6 host is more likely to have 1091 multiple addresses. 1093 This requires that the keystore maintain state about recent 1094 submissions over time and address. It may also be problematic for 1095 users who appear to share an IP address from the vantage of the 1096 keystore, including those behind a NAT, using a VPN, or accessing the 1097 keystore via Tor. 1099 6.4. Accept Certificates Based on Exterior Process 1101 Some public keystores resist abuse by explicitly filtering OpenPGP 1102 material based on a set of external processes. For example, 1103 [DEBIAN-KEYRING] adjudicates the contents of the "Debian keyring" 1104 keystore based on organizational procedure and manual inspection. 1106 6.5. Accept Certificates by E-mail Validation 1108 Some keystores resist abuse by declining any certificate until the 1109 user IDs have been verified by e-mail. When these "e-mail 1110 validating" keystores review a new certificate that has a user ID 1111 with an e-mail address in it, they send an e-mail to the associated 1112 address with a confirmation mechanism (e.g., a high-entropy HTTPS URL 1113 link) in it. The e-mail itself MAY be encrypted to an encryption- 1114 capable key found in the proposed certificate. If the keyholder 1115 triggers the confirmation mechanism, then the keystore accepts the 1116 certificate. 1118 Some e-mail validating keystores MAY choose to distribute 1119 certifications over all user IDs for any given certificate, but will 1120 redact (see Section 5.1) those user IDs that have not been e-mail 1121 validated. 1123 [PGP-GLOBAL-DIRECTORY] describes some concerns held by a keystore 1124 operator using this approach. [MAILVELOPE-KEYSERVER] is another 1125 example. 1127 7. Non-append-only mitigations 1129 The following mitigations may cause some previously-retained packets 1130 to be dropped after the keystore receives new information, or as time 1131 passes. This is entirely reasonable for some keystores, but it may 1132 be surprising for clients of a keystore that expect the keystore to 1133 be append-only (for example, some keyserver synchronization 1134 techniques may expect this property to hold). 1136 Furthermore, keystores that drop old data (e.g., superseded 1137 certifications) may make it difficult or impossible for their users 1138 to reason about the validity of signatures that were made in the 1139 past. See Section 11.5 for more considerations. 1141 Note also that many of these mitigations depend on cryptographic 1142 validation, so they're typically contextual as well. 1144 A keystore that needs to be append-only, or which cannot perform 1145 cryptographic validation MAY omit these mitigations. Alternately, a 1146 keystore may omit these mitigations at certificate ingestion time, 1147 but apply these mitigations at retrieval time (during certificate 1148 refresh, discovery, or lookup), and offer a more verbose (non- 1149 mitigated) interface for auditors, as described in Section 5. 1151 Note that [GnuPG] anticipates some of these suggestions with its 1152 "clean" subcommand, which is documented as: 1154 Compact (by removing all signatures except the selfsig) 1155 any user ID that is no longer usable (e.g. revoked, or 1156 expired). Then, remove any signatures that are not usable 1157 by the trust calculations. Specifically, this removes 1158 any signature that does not validate, any signature that 1159 is superseded by a later signature, revoked signatures, 1160 and signatures issued by keys that are not present on the 1161 keyring. 1163 7.1. Drop Superseded Signatures 1165 An abuse-resistant keystore SHOULD drop all signature packets that 1166 are explicitly superseded. For example, there's no reason to retain 1167 or distribute a self-sig by key K over User ID U from 2017 if the 1168 keystore have a cryptographically-valid self-sig over from 1169 2019. 1171 Note that this covers both certifications and signatures over 1172 subkeys, as both of these kinds of signature packets may be 1173 superseded. 1175 Getting this right requires a nuanced understanding of subtleties in 1176 [RFC4880] related to timing and revocation. 1178 7.2. Drop Expired Signatures 1180 If a signature packet is known to only be valid in the past, there is 1181 no reason to distribute it further. An abuse-resistant keystore with 1182 access to a functional real-time clock SHOULD drop all certifications 1183 and subkey signature packets with an expiration date in the past. 1185 Note that this assumes that the keystore and its clients all have 1186 roughly-synchronized clocks. If that is not the case, then there 1187 will be many other problems! 1189 7.3. Drop Dangling User IDs, User Attributes, and Subkeys 1191 If enough signature packets are dropped, it's possible that some of 1192 the things that those signature packets cover are no longer valid. 1194 An abuse-resistant keystore which has dropped all certifications that 1195 cover a User ID SHOULD also drop the User ID packet. 1197 Note that a User ID that becomes invalid due to revocation MUST NOT 1198 be dropped, because the User ID's revocation signature itself remains 1199 valid, and needs to be distributed. 1201 A primary key with no User IDs and no subkeys and no revocations MAY 1202 itself also be removed from distribution, though note that the 1203 removal of a primary key may make it impossible to cryptographically 1204 validate other certifications held by the keystore. 1206 7.4. Drop All Other Elements of a Directly-Revoked Certificate 1208 If the primary key of a certificate is revoked via a key revocation 1209 signature (type 0x20), an abuse-resistant keystore SHOULD drop all 1210 the rest of the associated data (user IDs, user attributes, and 1211 subkeys, and all attendant certifications and subkey signatures). 1212 This defends against an adversary who compromises a primary key and 1213 tries to flood the certificate to hide the revocation. 1215 Note that the key revocation signature MUST NOT be dropped. 1217 In the event that an abuse-resistant keystore is flooded with key 1218 revocation signatures, it should retain the hardest, earliest 1219 revocation (see also Section 12.1). 1221 In particular, if any of the key revocation signatures is a "hard" 1222 revocation, the abuse-resistant keystore SHOULD retain the earliest 1223 such revocation signature (by signature creation date). 1225 Otherwise, the abuse-resistant keystore SHOULD retain the earliest 1226 "soft" key revocation signature it has seen. 1228 If either of the above date comparisons results in a tie between two 1229 revocation signatures of the same "hardness", an abuse-resistant 1230 keystore SHOULD retain the signature that sorts earliest based on a 1231 binary string comparison of the key revocation signature packet 1232 itself. 1234 7.5. Implicit Expiration Date 1236 In combination with some of the dropping mitigations above, a 1237 particularly aggressive abuse-resistant keystore MAY choose an 1238 implicit expiration date for all signature packets. For example, a 1239 signature packet that claims no expiration could be treated by the 1240 keystore as expiring 3 years after issuance. This would permit the 1241 keystore to eject old packets on a rolling basis. 1243 An abuse-resistant keystore that adopts this mitigation needs a 1244 policy for handling signature packets marked with an explicit 1245 expiration that is longer than implicit maximum. The two obvious 1246 strategies are: 1248 * cap the packet's expiration to the system's implicit expiration 1249 date, or 1251 * accept the explicit expiration date. 1253 Warning: Any implementation of this idea is pretty radical, and it's 1254 not clear what it would do to an ecosystem that depends on such a 1255 keystore. It probably needs more thinking. 1257 8. Primary Key Sovereignty 1259 A keystore can defend against malicious external flooding by treating 1260 the "first party" of each certificate as "sovereign" over that 1261 certificate. This means in practice that no part of the certificate 1262 will redistributed without explicit permission from the primary key. 1263 We call a keystore that aims to respect primary key sovereignty a 1264 "sovereignty-respecting" keystore. 1266 [RFC4880] defines "Key Server Preferences" with a "No-modify" bit. 1267 That bit has never been respected by any keyserver implementation 1268 that the author is aware of. A sovereignty-respecting keystore 1269 effectively treats that bit as always set, whether it is present in 1270 any part of the certificate or not. 1272 A sovereignty-respecting abuse-resistant keystore can apply other 1273 constraints in addition to primary-key sovereignty, of course, for 1274 reasons as diverse as performance concerns, storage capacity, legal 1275 regulation, cryptographic algorithm support, or project policy. It 1276 will not redistribute anything that has not been explicitly approved 1277 by the primary key, but that does not mean it has to redistribute 1278 everything that has been explicitly approved by the primary key. 1280 The remaining subsections of Section 8 describe some sensible 1281 strategies for a sovereignty-respecting keystore. 1283 8.1. Refresh-only Keystores 1285 Some soveriegnty-respecting keystores may resist abuse by declining 1286 to accept any user IDs or certifications whatsoever. 1288 Such a keystore MUST be capable of cryptographic validation. It 1289 accepts primary key packets, cryptographically-valid direct-key and 1290 revocation signatures from a primary key over itself, subkeys and 1291 their cryptographically-validated binding signatures (and cross-sigs, 1292 where necessary). 1294 A client of a refresh-only keystore cannot possibly use the keystore 1295 for certificate lookup, because there are no user IDs to match. And 1296 it is not particularly useful for certificate discovery, because the 1297 returned certificate would have no identity information. However, 1298 such a keystore can be used for certificate refresh, as it's possible 1299 to ship revocations, new subkeys, updates to subkey expiration, 1300 subkey revocations, and updates of direct key signature-based 1301 certificate expiration or other OpenPGP properties. 1303 Note that many popular OpenPGP implementations do not implement 1304 direct primary key expiration mechanisms, relying instead on user ID 1305 expirations. These user ID expiration dates or other metadata 1306 associated with a self-certification will not be distributed by an 1307 refresh-only keystore. 1309 Certificates shipped by an refresh-only keystore are technically 1310 invalid [RFC4880] "transferable public keys," because they lack a 1311 user ID packet. However many OpenPGP implementations will accept 1312 such a certificate if they already know of a user ID for the 1313 certificate, because the composite certificate resulting from a merge 1314 will be a standards-compliant transferable public key. 1316 8.2. First-party-only Keystores 1318 Slightly more permissive than the refresh-only keystore described in 1319 Section 8.1 is a sovereignty-respecting keystore that also permits 1320 user IDs and their self-sigs. 1322 A first-party-only keystore only accepts and distributes 1323 cryptographically-valid first-party certifications. Given a primary 1324 key that the keystore understands, it will only attach user IDs that 1325 have a valid self-sig, and will only accept and re-distribute subkeys 1326 that are also cryptographically valid (including requiring cross-sigs 1327 for signing-capable subkeys as recommended in [RFC4880]). 1329 This effectively avoids certificate flooding attacks, because the 1330 only party who can make a certificate overly large is the holder of 1331 the secret corresponding to the primary key itself. 1333 Note that a first-party-only keystore is still problematic for those 1334 people who rely on the keystore for retrieval of third-party 1335 certifications. Section 8.3 attempts to address this lack. 1337 8.2.1. First-party-only Without User IDs 1339 It is possible to operate an first-party-only keystore that 1340 redistributes certifications (in particular, self-sigs) while 1341 declining to redistribute user IDs themselves (see Section 5.1). 1342 This defends against concerns about publishing identifiable 1343 information, while enabling full certificate refresh for those 1344 keystore clients that already know the associated user IDs for a 1345 given certificate. 1347 8.3. First-party-attested Third-party Certifications 1349 We can augment a first-party-only sovereignty-respecting keystore to 1350 allow it to distribute third-party certifications as long as the 1351 first-party has signed off on the specific third-party certification. 1353 This can be done by placing an Attested Certifications subpacket in 1354 the most recent self-sig of the certificate (see 1355 [Attested-Certifications]). 1357 8.3.1. Client Interactions 1359 Creating such an attestation requires multiple steps by different 1360 parties, each of which is blocked by all prior steps: 1362 * The first-party creates the certificate, and transfers it to the 1363 third party. 1365 * The third-party certifies it, and transfers their certification 1366 back to the first party. 1368 * The first party attests to the third party's certification by 1369 issuing a new self-sig. 1371 * Finally, the first party then transfers the updated certificate to 1372 the keystore. 1374 The complexity and length of such a sequence may represent a 1375 usability obstacle to a user who needs a third-party-certified 1376 OpenPGP certificate. 1378 Few OpenPGP clients can currently create the attestations described 1379 in [Attested-Certifications]. None that the author is aware of are 1380 user-friendly. More implementation work needs to be done to make it 1381 easy (and understandable) for a user to perform this kind of 1382 attestation. 1384 8.3.2. Revoking Third-party Certifications 1386 A sovereignty-respecting keystore distributes a third-party 1387 certification based on the desires of the first party, but the third- 1388 party themselves may change their mind about the certification that 1389 they issued. In particular, they may revoke a previously attested 1390 third-party certification. This causes some additional complexity. 1392 8.3.2.1. Third-party Certification Revocations Aren't Shipped with the 1393 Certificate 1395 Distributing the third-party's revocation of their certification 1396 without the approval of the first party would arguably disrespect the 1397 first-party's sovereignty over their own certificate. For example, 1398 consider an abusively large revocation, or a revocation which 1399 contains toxic data. 1401 At the same time, if the first party were to revoke their 1402 attestation, then the third-party certification itself _and_ its 1403 third-party's revocation might not be distributed. So distributing 1404 third-party certification revocations directly on the certificate 1405 they refer to doesn't seem to solve the problem for an abuse- 1406 resistant, sovereignty-respecting keystore. 1408 8.3.2.2. Third-party Certification Revocations Ship With the Issuing 1409 Certificate 1411 Instead, a sovereignty-respecting keystore MAY ship a third-party 1412 certification revocation attached to the end of the issuing 1413 certificate, as this respects the sovereignty of all parties 1414 involved. 1416 This means that the certifier's own OpenPGP certificate MAY be 1417 distributed like so: 1419 - A. Primary key 1420 - B. User ID 1421 - C. Self-sig (from A, binding A to B) 1422 - D. Subkey 1423 - E. Subkey binding signature (from A, binds D to A) 1424 - F. Certification revocation signature 1425 (from A over some other key+userID, targets other 1426 certification) 1428 Note that OpenPGP packet K is unusual here, and augments the 1429 traditional Transferable Public Key structure from [RFC4880]. 1431 A client that cares about third-party certifications SHOULD maintain 1432 an index of certifications based on the SHA256 digest of the 1433 certifications themselves (the "certification index"). The 1434 certification revocation packet SHOULD contain a Signature Target 1435 subpacket using SHA256 to identify the revoked certification. The 1436 client can use this Signature Target subpacket and the certification 1437 index to identify the targeted certification and to compute the data 1438 over which the revocation is made. This use of SHA256 is not used 1439 for cryptographic strength, but for indexing efficiency. 1441 A client that cares about third-party certifications from key A 1442 SHOULD refresh the certificate containing A from the keystore, and 1443 verify any discovered certification revocations correctly to the 1444 appropriate certificates, searching for the targeted revocation in 1445 its certification index. 1447 A legacy client that is unaware of this augmentation of the 1448 Transferable Public Key structure is likely to consider packet K as 1449 out-of-order or inapplicable (it would typically expect only a Subkey 1450 Revocation Signature packet in this position), and so will discard 1451 it. 1453 In the event that the certificate has no subkeys (packets I and J are 1454 absent), a legacy client might consider F to be an attempt to revoke 1455 Self-Sig C. However, F's Signature Target subpacket does not point 1456 to C, and the certification is not cryptographically valid over A and 1457 B, so it should be discarded/ignored safely in that case as well. 1459 9. Keystore Client Best Practices 1461 An OpenPGP client that needs to interact with an abuse-resistant 1462 keystore can take steps to minimize the extent that its interactions 1463 with a keystore can be abused by other parties via the attacks 1464 described in Section 2. This section describes steps that an abuse- 1465 resistant client can take. 1467 9.1. Use Constrained Keystores for Lookup 1469 When performing certificate lookup, an abuse-resistant client SHOULD 1470 prefer to query abuse-resistant keystores to avoid the risks 1471 described in Section 13.1. In particular, keystores that defend 1472 against User ID Flooding are significantly more reliable for 1473 certificate lookup. 1475 9.2. Normalize Addresses and User IDs for Lookup 1477 When performing lookup by e-mail address, an abuse-resistant client 1478 SHOULD consider canonicalizing the e-mail address before searching 1479 (see Section 12.3). 1481 When searching by full User ID, unless there is a strong reason to 1482 believe that a specific non-normalized form is preferable, an abuse- 1483 resistant client SHOULD normalize the entire user ID into 1484 [UNICODE-NORMALIZATION] Form C (NFC) before performing certificate 1485 lookup. 1487 9.3. Avoid Fuzzy Lookups 1489 Certificate lookup by arbitrary substring matching, or regular 1490 expression is prone to abuse. An abuse-resistant client SHOULD 1491 prefer exact-uid or exact-email match lookups where possible. 1493 In particular, an abuse-resistant client should avoid trying to offer 1494 reliable functionality that performs these sort of fuzzy lookups, and 1495 SHOULD warn the user about risks of abuse if the user triggers a 1496 codepath that unavoidably performs such a fuzzy lookup. 1498 9.4. Prefer Full Fingerprint for Discovery and Refresh 1500 Key IDs are inherently weaker and easier to spoof or collide than 1501 full fingerprints. Where possible, an abuse-resistant keystore 1502 client SHOULD use the full fingerprint when interacting with the 1503 keystore. 1505 9.5. Use Caution with Keystore-provided Validation 1507 When an abuse-resistant client relies on a keystore for certificate 1508 validation, many things can go subtly wrong if the client fails to 1509 closely track the specific semantics of the keystore's validation 1510 claims. 1512 For example, a certificate published by WKD 1513 ([I-D.koch-openpgp-webkey-service]) at 1514 https://openpgpkey.example.org/.well-known/openpgpkey/hu/ 1515 iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=joe.doe offers a validation claim 1516 only for the e-mail address joe.doe@example.org. If the certificate 1517 retrieved at that address contains other user IDs, or if the user ID 1518 containing that e-mail address contains an [RFC5322] display-name, 1519 none of that information should be considered "validated" by the fact 1520 that the certificate was retrieved via certificate lookup by WKD. 1522 When certificate validation is represented more generally by a 1523 keystore via certificate retrieval (e.g. from an e-mail validating 1524 keyserver that has no distinct certificate validation interface), the 1525 thing validated is the certificate received from the keystore, and 1526 not the result of the merge into any local copy of the certificate 1527 already possessed by the client. 1529 Consider also timing and duration of these assertions of validity, 1530 which represent a subtle tradeoff between privacy and risk as 1531 described in Section 14.4. 1533 10. Certificate Generation and Management Best Practices 1535 An OpenPGP implementation that generates or manages certificates and 1536 expects to distribute them via abuse-resistant keystores can take 1537 steps to ensure that the certificates generated are more likely to be 1538 accessible when needed. This section describes steps such an abuse- 1539 sensitive implementation can take. 1541 10.1. Canonicalized E-Mail Addresses 1543 E-mail addresses can be written in many different ways. An abuse- 1544 sensitive implementation considering attaching a user ID containing 1545 an e-mail address on a certificate SHOULD ensure that the e-mail 1546 address is structured as simply as possible. See Section 12.3 for 1547 details about e-mail address canonicalization. 1549 For example, if the e-mail domain considers the local part to be 1550 case-insensitive (as most e-mail domains do today), if a proposed 1551 user ID contains the addr-spec: Alice@EXAMPLE.org, the implementation 1552 SHOULD warn the user and, if possible, propose replacing the addr- 1553 spec part of the user ID with alice@example.org. 1555 10.2. Normalized User IDs 1557 User IDs are arbitrary UTF-8 strings, but UTF-8 offers several ways 1558 to represent the same string. An abuse-sensitive implementation 1559 considering attaching a user ID to a certificate SHOULD normalize the 1560 string using [UNICODE-NORMALIZATION] Form C (NFC) before creating the 1561 self-sig. 1563 At the same time, the implementation MAY also warn the user if the 1564 "compatibility" normalized form (NFKC) differs from the candidate 1565 user ID and, if appropriate, offer to convert the user ID to 1566 compatibility normalized form at the user's discretion. 1568 10.3. Avoid Large User Attributes 1570 An abuse-sensitive implementation SHOULD warn the user when attaching 1571 a user attribute larger than 8383 octets, and SHOULD refuse to attach 1572 user attributes entirely larger than 65536 octets. (See Section 4.1) 1574 10.4. Provide Cross-Sigs 1576 [RFC4880] requires cross-sigs for all signing-capable subkeys, but is 1577 agnostic about the use of cross-sigs for subkeys of other 1578 capabilities. 1580 An abuse-sensitive implementation that wants a certificate to be 1581 discoverable by subkey SHOULD provide cross-sigs for any subkey 1582 capable of making a cross-sig. 1584 10.5. Provide Issuer Fingerprint Subpackets 1586 Issuer subpackets contain only 64-bit key IDs. Issuer Fingerprint 1587 subpackets contain an unambiguous designator of the issuing key, 1588 avoiding the ambiguities described in Section 11.2. Abuse-sensitive 1589 implementations SHOULD provide Issuer Fingerprint subpackets. 1591 10.6. Put Cross-Sigs and Issuer Fingerprint in Hashed Subpackets 1593 Unhashed subpackets may be stripped or mangled. Placing cross-sigs 1594 and issuer fingerprint subpackets in the hashed subpackets will 1595 ensure that they are propagated by any cryptographically-validating 1596 keystore, even if that keystore fails to observe the exceptions in 1597 Section 4.4. 1599 10.7. Submit Certificates to Restricted, Lookup-Capable Keystores 1601 If an abuse-sensitive implementation wants other peers to be able to 1602 to retrieve the managed certificate by certificate lookup (that is, 1603 by searching based on user ID or e-mail address), it needs to be 1604 aware that submission to an unrestricted keystore is not reliable 1605 (see Section 13.1 for more details). 1607 Consequently, such an implementation SHOULD submit the managed 1608 certificate to restricted, lookup-capable keystores where possible, 1609 as those keystores are more likely to be able to offer reliable 1610 lookup. 1612 11. Side Effects and Ecosystem Impacts 1614 11.1. Designated Revoker 1616 A first-party-only keystore as described in Section 8.2 might decline 1617 to distribute revocations made by the designated revoker. This is a 1618 risk to certificate-holder who depend on this mechanism, because an 1619 important revocation might be missed by clients depending on the 1620 keystore. 1622 FIXME: adjust this document to point out where revocations from a 1623 designated revoker SHOULD be propagated, maybe even in first-party- 1624 only keystores. 1626 11.2. Key IDs vs. Fingerprints in Certificate Discovery 1628 During signature verification, a user performing certificate 1629 discovery against a keystore SHOULD prefer to use the full 1630 fingerprint as an index, rather than the 64-bit key ID. Using a 1631 64-bit key ID is more likely to run into collision attacks; and if 1632 the retrieved certificate has a matching key ID but the signature 1633 cannot be validated with it, the client is in an ambiguous state -- 1634 did it retrieve the wrong certificate, or is the signature incorrect? 1635 Using the fingerprint resolves the ambiguity: the signature is 1636 incorrect, because the a fingerprint match is overwhelmingly stronger 1637 than a key ID match. 1639 Unfortunately, many OpenPGP implementations distribute signatures 1640 with only an Issuer subpacket, so a client attempting to find such a 1641 certificate MAY perform certificate discovery based on only the key 1642 ID. 1644 A keystore that offers certificate discovery MAY choose to require 1645 full fingerprint, but such a keystore will not be useful for a client 1646 attempting to verify a bare signature from an unknown party if that 1647 signature only has an Issuer subpacket (and no Issuer Fingerprint 1648 subpacket). 1650 11.3. In-band Certificates 1652 There are contexts where it is expected and acceptable that the 1653 signature appears without its certificate: for example, if the set of 1654 valid signers is already known (as in some OpenPGP-signed operating 1655 system updates), shipping the certificate alongside the signature 1656 would be pointless bloat. 1658 However, OpenPGP signatures are often found in contexts where the 1659 certificate is not yet known by the verifier. For example, many 1660 OpenPGP-signed e-mails are not accompanied by the signing 1661 certificate. 1663 In another example, the use of authentication-capable OpenPGP keys in 1664 standard SSH connections do not contain the full OpenPGP 1665 certificates, which means that the SSH clients and servers need to 1666 resort to out-of-band processes if evaluation of the OpenPGP 1667 certificates is necessary. 1669 The certificate discovery interface offered by keystores is an 1670 attempt to accommodate these situations. But in the event that a 1671 keystore is unavailable, does not know the certificate, or suffers 1672 from a flooding attack, signature validation may fail unnecessarily. 1673 In an encrypted e-mail context specifically, such a failure may also 1674 limit the client's ability to reply with an encrypted e-mail. 1676 Certificate discovery also presents a potential privacy concern for 1677 the signature verifier, as noted in Section 14.5. 1679 These problematic situations can be mitigated by shipping the 1680 certificate in-band, alongside the signature. Signers SHOULD adopt 1681 this practice where possible to reduce the dependence of the verifier 1682 on the keystores for certificate discovery. [AUTOCRYPT] is an 1683 example of e-mail recommendations that include in-band certificates. 1685 11.3.1. In-band Certificate Minimization and Validity 1687 OpenPGP certificates are potentially large. When distributing an in- 1688 band certificate alongside a signature in a context where size is a 1689 concern (e.g. bandwidth, latency, or storage costs are a factor), the 1690 distributor SHOULD reduce the size of the in-band certificate by 1691 stripping unnecessary packets. For example, the distributor may: 1693 * Strip certification and signature packets that (due to creation 1694 and expiration time) are not relevant to the time of the signature 1695 itself. This ensures that the reduced certificate is 1696 contemporaneously valid with the signature. 1698 * Strip irrelevant subkeys (and associated Subkey Binding Signature 1699 packets and cross-sigs). If the signature was issued by a 1700 signing-capable subkey, that subkey (and its binding signature and 1701 cross-sig) are clearly relevant. Other signing-capable subkeys 1702 are likely to be irrelevant. But determining which other subkeys 1703 are relevant may be context-specific. For example, in the e-mail 1704 context, an encryption-capable subkey is likely to be contextually 1705 relevant, because it enables the recipient to reply encrypted, and 1706 therefore should not be stripped. 1708 * Strip user IDs (and associated certifications) that are unlikely 1709 to be relevant to the signature in question. For example, in the 1710 e-mail context, strip any user IDs that do not match the declared 1711 sender of the message. 1713 * Strip third-party certifications that are unlikely to be relevant 1714 to the verifier. Doing this successfully requires some knowledge 1715 about what the third-parties the recipient is likely to care 1716 about. Stripping all third-party certifications is a simple means 1717 of certificate reduction. The verifier of such a certificate may 1718 need to do certificate refresh against their preferred keystore to 1719 learn about third-party certifications useful to them. 1721 11.4. Certification-capable Subkeys 1723 Much of this discussion assumes that primary keys are the only 1724 certification-capable keys in the OpenPGP ecosystem. Some proposals 1725 have been put forward that assume that subkeys can be marked as 1726 certification-capable. If subkeys are certification-capable, then 1727 much of the reasoning in this draft becomes much more complex, as 1728 subkeys themselves can be revoked by their primary key without 1729 invalidating the key material itself. That is, a subkey can be both 1730 valid (in one context) and invalid (in another context) at the same 1731 time. So questions about what data can be dropped (e.g. in 1732 Section 7) are much fuzzier, and the underlying assumptions may need 1733 to be reviewed. 1735 If some OpenPGP implementations accept certification-capable subkeys, 1736 but an abuse-resistant keystore does not accept certifications from 1737 subkeys in general, then interactions between that keystore and those 1738 implementations may be surprising. 1740 11.5. Assessing Certificates in the Past 1742 Online protocols like TLS perform signature and certificate 1743 evaluation based entirely on the present time. If a certificate that 1744 signs a TLS handshake message is invalid now, it doesn't matter 1745 whether it was valid a week ago, because the present TLS session is 1746 the context of the evaluation. 1748 But OpenPGP signatures are often evaluated at some temporal remove 1749 from when the signature was made. For example, software packages are 1750 signed at release time, but those signatures are validated at 1751 download time. A verifier that does not already know the certificate 1752 that made the signature will need to perform certificate discovery 1753 against some set of keystores to find a certificate with which to 1754 check the signature. 1756 Further complicating matters, the composable nature of an OpenPGP 1757 certificate means that the certificate associated with any particular 1758 signing key (primary key or subkey) can transform over time. So when 1759 evaluating a signature that appears to have been made by a given 1760 certificate, it may be better to try to evaluate the certificate at 1761 the time the signature was made, rather than the present time. 1763 11.5.1. Point-in-time Certificate Evaluation 1765 When evaluating a certificate at a time T in the past (for example, 1766 when trying to validate a data signature by that certificate that was 1767 created at time T), one approach is to discard all packets from the 1768 certificate if the packet has a creation time later than T. Then 1769 evaluate the resulting certificate from the remaining packets in the 1770 context of time T. 1772 However, any such evaluation MUST NOT ignore "hard" OpenPGP key 1773 revocations, regardless of their creation date. (see Section 12.1). 1775 11.5.2. Signature Verification and Non-append-only Keystores 1777 If a non-append-only keystore (Section 7) has dropped superseded 1778 (Section 7.1) or expired (Section 7.2) certifications, it's possible 1779 for the certificate composed of the remaining packets to have no 1780 valid first-party certification at the time that a given signature 1781 was made. If a user performs certificate discovery against such a 1782 keystore, the certificate it retrieves would be invalid according to 1783 [RFC4880], and consequently verification of any signature by that 1784 certificate would fail. 1786 One simple mitigation to this problem is to ship a contemporaneously- 1787 valid certificate in-band alongside the signature (see Section 11.3). 1789 If the distributor does this, then the verifier need only learn about 1790 revocations. If knowledge about revocation is needed, the verifier 1791 might perform a certificate refresh (not "certificate discovery") 1792 against any preferred keystore, including non-append-only keystores, 1793 merging what it learns into the in-band contemporary certificate. 1795 Then the signature verifier can follow the certificate evaluation 1796 process outlined in Section 11.5.1, using the merged certificate. 1798 11.6. Global Append-only Ledgers ("Blockchain") 1800 The append-only aspect of some OpenPGP keystores encourages a user of 1801 the keystore to rely on that keystore as a faithful reporter of 1802 history, and one that will not misrepresent or hide the history that 1803 they know about. An unfaithful "append-only" keystore could abuse 1804 the trust in a number of ways, including withholding revocation 1805 certificates, offering different sets of certificates to different 1806 clients doing certificate lookup, and so on. 1808 However, the most widely used append-only OpenPGP keystore, the [SKS] 1809 keyserver pool, offers no cryptographically verifiable guarantees 1810 that it will actually remain append-only. Users of the pool have 1811 traditionally relied on its distributed nature, and the presumption 1812 that coordination across a wide range of administrators would make it 1813 difficult for the pool to reliably lie or omit data. However, the 1814 endpoint most commonly used by clients to access the network is 1815 hkps://hkps.pool.sks-keyservers.net, the default for [GnuPG]. That 1816 endpoint is increasingly consolidated, and currently consists of 1817 hosts operated by only two distinct administrators, increasing the 1818 risk of potential misuse. 1820 Offering cryptographic assurances that a keystore could remain 1821 append-only is an appealing prospect to defend against these kinds of 1822 attack. Many popular schemes for providing such assurances are known 1823 as "blockchain" technologies, or global append-only ledgers. 1825 With X.509 certificates, we have a semi-functional Certificate 1826 Transparency ([RFC6962], or "CT") ecosystem that is intended to 1827 document and preserve evidence of (mis)issuance by well-known 1828 certificate authorities (CAs), which implements a type of global 1829 append-only ledger. While the CT infrastructure remains vulnerable 1830 to certain combinations of colluding actors, it has helped to 1831 identify and sanction some failing CAs. 1833 Like other global append-only ledgers, CT itself is primarily a 1834 detection mechanism, and has no enforcement regime. If a widely-used 1835 CA were identified by certificate transparency to be untrustworthy, 1836 the rest of the ecosystem still needs to figure out how to impose 1837 sanctions or apply a remedy, which may or may not be possible. 1839 CT also has privacy implications -- the certificates published in the 1840 CT logs are visible to everyone, for the lifetime of the log. 1842 For spam abatement, CT logs decline all X.509 certificates except 1843 those issued by certain CAs (those in popular browser "root stores"). 1844 This is an example of the strategy outlined in Section 4.9). 1846 Additional projects that provide some aspects of global append-only 1847 ledgers that try to address some of the concerns described here 1848 include [KEY-TRANSPARENCY] and [CONIKS], though they are not specific 1849 to OpenPGP. Both of these systems are dependent on servers operated 1850 by identity providers, however. And both offer the ability to detect 1851 a misbehaving identity provider, but no specific enforcement or 1852 recovery strategies against such an actor. 1854 It's conceivable that a keystore could piggyback on the CT logs or 1855 other blockchain/ledger mechanisms like [BITCOIN] to store 1856 irrevocable pieces of data (such as revocation certificates). 1857 Further work is needed to describe how to do this in an effective and 1858 performant way. 1860 11.7. Certificate Lookup for Identity Monitoring 1862 While certificate lookup is classically used to find a key to encrypt 1863 an outbound message to, another use case for certificate lookup is 1864 for the party in control of a particular identity to determine 1865 whether anyone else is claiming that identity. 1867 That is, a client in control of the secret key material associated 1868 with a particular certificate with user ID X might search a keystore 1869 for all certificates matching X in order to find out whether any 1870 other certificates claim it. 1872 This is an important safeguard as part of the ledger-based detection 1873 mechanisms described in Section 11.6, but may also be useful for 1874 keystores in general. 1876 However, identity monitoring against a keystore that does not defend 1877 against user ID flooding (Section 2.2) is expensive and potentially 1878 of limited value. In particular, a malicious actor with a 1879 certificate which duplicates a given User ID could flood the keystore 1880 with similar certificates, hiding whichever one is in malicious use. 1882 Since such a keystore is not considered authoritative by any 1883 reasonable client for the user ID in question, this attack forces the 1884 identity-monitoring defender to spend arbitrary resources fetching 1885 and evaluating each certificate in the flood, without knowing which 1886 certificate other clients might be evaluating. 1888 12. OpenPGP details 1890 This section collects details about common OpenPGP implementation 1891 behavior that are useful in evaluating and reasoning about OpenPGP 1892 certificates. 1894 12.1. Revocations 1896 It's useful to classify OpenPGP revocations of key material into two 1897 categories: "soft" and "hard". 1899 If the "Reason for Revocation" of an OpenPGP key is either "Key is 1900 superseded" or "Key is retired and no longer used", it is a "soft" 1901 revocation. 1903 An implementation that interprets a "soft" revocation will typically 1904 not invalidate signatures made by the associated key with a creation 1905 date that predates the date of the soft revocation. A "soft" 1906 revocation in some ways behaves like a non-overridable expiration 1907 date. 1909 All other revocations of OpenPGP keys (with any other Reason for 1910 Revocation, or with no Reason for Revocation at all) should be 1911 considered "hard". 1913 The presence of a "hard" revocation of an OpenPGP key indicates that 1914 the user should reject all signatures and certifications made by that 1915 key, regardless of the creation date of the signature. 1917 Note that some OpenPGP implementations do not distinguish between 1918 these two categories. 1920 A defensive OpenPGP implementation that does not distinguish between 1921 these two categories SHOULD treat all revocations as "hard". 1923 An implementation aware of a "soft" revocation or of key or 1924 certificate expiry at time T SHOULD accept and process a "hard" 1925 revocation even if it appears to have been issued at a time later 1926 than T. 1928 12.2. User ID Conventions 1930 [RFC4880] requires a user ID to be a UTF-8 string, but does not 1931 constrain it beyond that. In practice, a handful of conventions 1932 predominate in how User IDs are formed. 1934 The most widespread convention is a name-addr as defined in 1935 [RFC5322]. For example: 1937 Alice Jones 1939 But a growing number of OpenPGP certificates contain user IDs that 1940 are instead a raw [RFC5322] addr-spec, omitting the display-name and 1941 the angle brackets entirely, like so: 1943 alice@example.org 1945 Some certificates have user IDs that are simply normal human names 1946 (perhaps display-name in [RFC5322] jargon, though not necessarily 1947 conforming to a specific ABNF). For example: 1949 Alice Jones 1951 Still other certificates identify a particular network service by 1952 scheme and hostname. For example, the administrator of an ssh host 1953 participating in the [MONKEYSPHERE] might choose a user ID for the 1954 OpenPGP representing the host like so: 1956 ssh://foo.example.net 1958 12.3. E-mail Address Canonicalization 1960 When an OpenPGP user IDs includes an addr-spec, there still may be 1961 multiple ways of representing the addr-spec that refer to the same 1962 underlying mailbox. Having a truly canonical form of an addr-spec is 1963 probably impossible because of legacy deployments of mailservers that 1964 do odd things with the local part, but e-mail addresses used in an 1965 abuse-resistant ecosystem SHOULD be constrained enough to admit to 1966 some sensible form of canonicalization. 1968 12.3.1. Disallowing Non-UTF-8 Local Parts 1970 In [RFC5322], the local-part can be any dot-atom. But if this is 1971 [RFC2047] decoded, it could be any arbitrary charset, not necessarily 1972 UTF-8. FIXME: Do we convert from the arbitrary charset to UTF-8? 1974 12.3.2. Domain Canonicalization 1976 FIXME: should domain name be canonicalized into punycode form? User 1977 IDs are typically user-facing, so i think the canonicalized form 1978 should be the [UNICODE-NORMALIZATION] Form C (NFC) of the domain 1979 name. Can we punt to some other draft here? 1981 12.3.3. Local Part Canonicalization 1983 FIXME: [I-D.koch-openpgp-webkey-service] recommends downcasing all 1984 ASCII characters in the left-hand side, but leaves all 1986 13. Security Considerations 1988 This document offers guidance on mitigating a range of denial-of- 1989 service attacks on public keystores, so the entire document is in 1990 effect about security considerations. 1992 Many of the mitigations described here defend individual OpenPGP 1993 certificates against flooding attacks (see Section 2.1). But only 1994 some of these mitigations defend against flooding attacks against the 1995 keystore itself (see Section 2.4), or against flooding attacks on the 1996 space of possible user IDs (see Section 2.2). Thoughtful threat 1997 modeling and monitoring of the keystore and its defenses are probably 1998 necessary to maintain the long-term health of the keystore. 2000 Section 11.1 describes a potentially scary security problem for 2001 designated revokers. 2003 TODO (more security considerations) 2005 13.1. Tension Between Unrestricted Uploads and Certificate Lookup 2007 Note that there is an inherent tension between accepting arbitrary 2008 certificate uploads and permitting effective certificate lookup. If 2009 a keystore accepts arbitrary certificate uploads for redistribution, 2010 it appears to be vulnerable to user ID flooding (Section 2.2), which 2011 makes it difficult or impossible to rely on for certificate lookup. 2013 In the broader ecosystem, it may be necessary to use gated/controlled 2014 certificate lookup mechanisms. For example, both 2015 [I-D.koch-openpgp-webkey-service] and [RFC7929] enable the 2016 administrator of a DNS domain to distribute certificates associated 2017 with e-mail addresses within that domain, while excluding other 2018 parties. As a rather different example, [I-D.mccain-keylist] offers 2019 certificate lookup on the basis of interest -- a client interested in 2020 an organization can use that mechanism to learn what certificates 2021 that organization thinks are worth knowing about, associated with a 2022 range of identities regardless of the particular DNS domain. Note 2023 that [I-D.mccain-keylist] does not provide the certificates directly, 2024 but instead expects the client to be able to retrieve them by primary 2025 key fingerprint through some other keystore capable of (and 2026 responsible for) certificate refresh. 2028 14. Privacy Considerations 2030 Keystores themselves raise a host of potential privacy concerns. 2031 Additional privacy concerns are raised by traffic to and from the 2032 keystores. This section tries to outline some of the risks to the 2033 privacy of people whose certificates are stored and redistributed in 2034 public keystores, as well as risks to the privacy of people who make 2035 use of the key stores for certificate lookup, certificate discovery, 2036 or certificate refresh. 2038 14.1. Publishing Identity Information 2040 Public OpenPGP keystores often distribute names or e-mail addresses 2041 of people. Some people do not want their names or e-mail addresses 2042 distributed in a public keystore, or may change their minds about it 2043 at some point. Append-only keystores are particularly problematic in 2044 that regard. The mitigation in Section 7.4 can help such users strip 2045 their details from keys that they control. However, if an OpenPGP 2046 certificate with their details is uploaded to a keystore, but is not 2047 under their control, it's unclear what mechanisms can be used to 2048 remove the certificate that couldn't also be exploited to take down 2049 an otherwise valid certificate. 2051 Some jurisdictions may present additional legal risk for keystore 2052 operators that distribute names or e-mail addresses of non-consenting 2053 parties. 2055 Refresh-only keystores (Section 8.1) and user ID redacting keystores 2056 (Section 5.1) may reduce this particular privacy concern because they 2057 distribute no user IDs at all. 2059 14.2. Social Graph 2061 Third-party certifications effectively map out some sort of social 2062 graph. A certification asserts a statement of belief by the issuer 2063 that the real-world party identified by the user ID is in control of 2064 the subject cryptographic key material. But those connections may be 2065 potentially sensitive, and some people may not want these maps built. 2067 A first-party-only keyserver (Section 8.2) avoids this privacy 2068 concern because it distributes no third-party privacy concern. 2070 First-party attested third-party certifications described in 2071 Section 8.3 are even more relevant edges in the social graph, because 2072 their bidirectional nature suggests that both parties are aware of 2073 each other, and see some value in mutual association. 2075 14.3. Tracking Clients by Queries 2077 Even without third-party certifications, the acts of certificate 2078 lookup, certificate discovery, and certificate refresh represent a 2079 potential privacy risk, because the keystore queried gets to learn 2080 which user IDs (in the case of lookup) or which certificates (in the 2081 case of refresh or discovery) the client is interested in. In the 2082 case of certificate refresh, if a client attempts to refresh all of 2083 its known certificates from the same keystore, that set is likely to 2084 be a unique set, and therefore identifies the client. A keystore 2085 that monitors the set of queries it receives might be able to profile 2086 or track those clients who use it repeatedly. 2088 A privacy-aware client which wants to to avoid such a tracking attack 2089 MAY try to perform certificate refresh from multiple different 2090 keystores. To hide network location, a client making a network query 2091 to a keystore SHOULD use an anonymity network like [TOR]. Tools like 2092 [PARCIMONIE] are designed to facilitate this type of certificate 2093 refresh. Such a client SHOULD also decline to use protocol features 2094 that permit linkability across interactions with the same keystore, 2095 such as TLS session resumption, HTTP cookies, and so on. 2097 Keystores which permit public access and want to protect the privacy 2098 of their clients SHOULD NOT reject access from clients using [TOR] or 2099 comparable anonymity networks. Additionally, they SHOULD minimize 2100 access logs they retain. 2102 Alternately, some keystores may distribute their entire contents to 2103 any interested client, in what can be seen as the most trivial form 2104 of private information retrieval. [DEBIAN-KEYRING] is one such 2105 example; its contents are distributed as an operating system package. 2106 Clients can interrogate their local copy of such a keystore without 2107 exposing their queries to a third-party. 2109 14.4. "Live" Certificate Validation Leaks Client Activity 2111 If a client relies on a keystore's certificate validation interface, 2112 or on the presence of a certificate in a keystore as a part of its 2113 validation calculations, it's unclear how long the assertion from the 2114 keystore is or should be considered to hold. One seemingly simple 2115 approach is to simply query the keystore's validation interface each 2116 time that the client needs to validate the certificate. 2118 This "live" validation approach poses a quandary to the client in the 2119 event that the keystore is unavailable. How should in interpret the 2120 "unknown" result? In addition, live validation reveals the client's 2121 activity to the keystore with fine precision. 2123 A privacy-aware client that depends on keystores for certificate 2124 validation SHOULD NOT perform "live" certificate validation on each 2125 use it makes of the certificate. Rather, it SHOULD cache the 2126 validation information for some period of time and make use of the 2127 cached copy where possible. If such a client does a regular 2128 certificate refresh from the same keystore, it SHOULD also pre- 2129 emptively query the keystore for certificate validation at the same 2130 time. 2132 Choosing the appropriate time intervals for this kind of caching has 2133 implications for the windows of risk for the client that might use a 2134 revoked certificate. Defining an appropriate schedule to make this 2135 tradeoff is beyond the scope of this document. 2137 14.5. Certificate Discovery Leaks Client Activity 2139 The act of doing certificate discovery on unknown signatures offers a 2140 colluding keystore and remote peer a chance to track a client's 2141 consumption of a given signature. 2143 An attacker with access to keystore logs could sign a message with a 2144 unique key, and then watch the keystore activity to determine when a 2145 client consumes the signature. This is potentially a tracking or 2146 "phone-home" situation. 2148 A signer that has no interest in this particular form of tracking can 2149 mitigate this concern by shipping their certificate in-band, 2150 alongside the signature, as recommended in Section 11.3. 2152 A privacy-aware client MAY insist on in-band certificates by 2153 declining to use any certificate discovery interface at all, and 2154 treat a bare signature by an unknown certificate as an invalid 2155 signature. 2157 14.6. Certificate Refresh Leaks Client Activity 2159 The act of doing certificate refresh itself reveals some information 2160 that the client is interested in a given certificate and how it may 2161 have changed since the last time the client refreshed it, or since it 2162 was first received by the client. 2164 This is essentially the same privacy problem presented by OCSP 2165 [RFC6960] in the X.509 world. In the online world of TLS, this 2166 privacy leak is mitigated by the CertificateStatus TLS handshake 2167 extension ([RFC4366]), a.k.a. "OCSP stapling". There is no 2168 comparable solution for the store-and-forward or non-online scenarios 2169 where OpenPGP is often found. 2171 Privacy-aware clients MAY prefer to access refresh interfaces from 2172 anonymity-preserving networks like [TOR] to obscure where they are on 2173 the network, but if the certificate being refreshed is known to be 2174 used only by a single client that may not help. 2176 Privacy-aware clients MAY prefer to stage their certificate refreshes 2177 over time, but longer delays imply greater windows of vulnerability 2178 for use of an already-revoked certificate. This strategy also does 2179 not help when a previously-unknown certificate is encountered in-band 2180 (see Section 11.3), and the OpenPGP client wants to evaluate it for 2181 use in the immediate context. 2183 14.7. Distinct Keystore Interfaces Leak Client Context and Intent 2185 The distinct keystore interfaces documented in Section 3 offer subtly 2186 different semantics, and are used by a reasonable keystore client at 2187 different times. A keystore that offers distinct discovery and 2188 refresh interfaces may infer that a client visiting the refresh 2189 interface already knows about the certificate in question, or that a 2190 client visiting the discovery interface is in the process of 2191 verifying a signature from a certificate it has not seen before. 2193 HKP itself ([I-D.shaw-openpgp-hkp]) conflates these two interfaces -- 2194 the same HKP query is be used to perform both discovery and refresh 2195 (though implementations like [SKS] are not at all abuse-resistant for 2196 either use), which may obscure the context and intent of the client 2197 from the keystore somewhat. 2199 A privacy-aware client that can afford the additional bandwidth and 2200 complexity MAY use the keystore's discovery interface for both 2201 refresh and discovery, since the discovery interface is a proper 2202 superset of the refresh interface. 2204 14.8. Cleartext Queries 2206 If access to the keystore happens over observable channels (e.g., 2207 cleartext connections over the Internet), then a passive network 2208 monitor could perform the same type profiling or tracking attack 2209 against clients of the keystore described in Section 14.3. Keystores 2210 which offer network access SHOULD provide encrypted transport. 2212 14.9. Traffic Analysis 2214 Even if a keystore offers encrypted transport, the size of queries 2215 and responses may provide effective identification of the specific 2216 certificates fetched during lookup, discovery, or refresh, leaving 2217 open the types of tracking attacks described in Section 14.3. 2218 Clients of keystores SHOULD pad their queries to increase the size of 2219 the anonymity set. And keystores SHOULD pad their responses. 2221 The appropriate size of padding to effectively anonymize traffic to 2222 and from keystores is likely to be mechanism- and cohort-specific. 2223 For example, padding for keystores accessed via the DNS ([RFC7929] 2224 may use different padding strategies that padding for keystores 2225 accessed over WKD ([I-D.koch-openpgp-webkey-service]), which may in 2226 turn be different from keystores accessed over HKPS 2227 ([I-D.shaw-openpgp-hkp]). A keystore which only accepts user IDs 2228 within a specific domain (e.g., Section 4.3) or which uses custom 2229 process (Section 6.4) for verification might have different padding 2230 criteria than a keystore that serves the general public. 2232 Specific padding policies or mechanisms are out of scope for this 2233 document. 2235 15. User Considerations 2237 Section 8.3.1 describes some outstanding work that needs to be done 2238 to help users understand how to produce and distribute a third-party- 2239 certified OpenPGP certificate to an abuse-resistant keystore. 2241 Additionally, some keystores present directly user-facing 2242 affordances. For example, [SKS] keyservers typically offer forms and 2243 listings that can be viewed directly in a web browser. Such a 2244 keystore SHOULD be as clear as possible about what abuse mitigations 2245 it takes (or does not take), to avoid user confusion. 2247 Keystores which do not expect to be used directly as part of a 2248 certificate validation calculation SHOULD advise clients as 2249 explicitly as possible that they offer no assertions of validity. 2251 Experience with the [SKS] keyserver network shows that many users 2252 treat the keyserver web interfaces as authoritative. That is, users 2253 act as though the keyserver network offers some type of certificate 2254 validation. Unfortunately, The developer and implementor communities 2255 explicitly disavow any authoritative role in the ecosystem, and the 2256 implementations attempt very few mitigations against abuse, 2257 permitting redistribution of even cryptographically invalid OpenPGP 2258 packets. Clearer warnings to end users might reduce this kind of 2259 misperception. Or the community could encourage the removal of 2260 frequently misinterpreted user interfaces entirely. 2262 16. IANA Considerations 2264 This document asks IANA to register two entries in the OpenPGP 2265 Notation IETF namespace, both with a reference to this document: 2267 * the "uidhash" notation is defined in Section 5.1.4. 2269 16.1. Document History 2271 substantive changes bewteen -04 and -05: 2273 * Clarify distinctions between different signature types 2275 * Point to Attested Certifications proposal 2277 * Formatting changes: use xml2rfc v3, publish editor's copy 2279 substantive changes bewteen -03 and -04: 2281 * change "certificate update" to "certificate refresh" for clarity 2282 * relax first-party-attested third-party certification constraints 2283 at the suggestion of Valodim 2285 * introduce "primary key sovereignty" concept explicitly 2287 * describe how to distribute and consume attestation revocations 2289 * introduce augmentation to TPK for third-party certification 2290 revocation distribution 2292 substantive changes between -02 and -03: 2294 * new sections: 2296 - Keystore Interfaces 2298 - Keystore Client Best Practices 2300 - Certificate Generation and Management Best Practices 2302 * rename "certificate discovery" to "certificate lookup" 2304 * redefine "certificate discovery" to refer to lookup by signing 2305 (sub)key 2307 * new attack: fingerprint flooding 2309 * new retrieval-time mitigations -- tighter filters on discovery and 2310 update 2312 * recommend in-band certificates where possible to avoid discovery 2313 and lookup 2315 * new privacy considerations: 2317 - distinct keystore interfaces 2319 - certificate update 2321 - certificate discovery 2323 - certificate validation 2325 * more nuance about unhashed subpacket filtering 2327 substantive changes between -01 and -02: 2329 * distinguish different forms of flooding attack 2330 * distinguish toxic data as distinct from flooding 2332 * retrieval-time mitigations 2334 * user ID redaction 2336 * references to related work (CT, keylist, CONIKS, key transparency, 2337 ledgers/"blockchain", etc) 2339 * more details about UI/UX 2341 substantive changes between -00 and -01: 2343 * split out Contextual and Non-Append-Only mitigations 2345 * documented several other mitigations, including: 2347 - Decline Data From the Future 2349 - Blocklist 2351 - Exterior Process 2353 - Designated Authorities 2355 - Known Certificates 2357 - Rate-Limiting 2359 - Scoped User IDs 2361 * documented Updates-Only Keystores 2363 * consider three different kinds of flooding 2365 * deeper discussion of privacy considerations 2367 * better documentation of Reason for Revocation 2369 * document user ID conventions 2371 17. Acknowledgements 2373 This document is the result of years of operational experience and 2374 observation, as well as conversations with many different people -- 2375 users, implementors, keystore operators, etc. A non-exhaustive list 2376 of people who have contributed ideas or nuance to this document 2377 specifically includes: 2379 * Antoine Beaupre 2381 * Heiko Stamer 2383 * ilf 2385 * Jamie McClelland 2387 * Jon Callas 2389 * Jonathan McDowell 2391 * Justus Winter 2393 * Marcus Brinkmann 2395 * Micah Lee 2397 * Neal Walfield 2399 * Phil Pennock 2401 * Philihp Busby 2403 * vedaal 2405 * Vincent Breitmoser 2407 * Wiktor Kwapisiewicz 2409 18. References 2411 18.1. Normative References 2413 [I-D.ietf-openpgp-rfc4880bis] 2414 Koch, W., carlson, B. M., Tse, R. H., Atkins, D., and D. 2415 K. Gillmor, "OpenPGP Message Format", Work in Progress, 2416 Internet-Draft, draft-ietf-openpgp-rfc4880bis-10, 31 2417 August 2020, . 2420 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 2421 Part Three: Message Header Extensions for Non-ASCII Text", 2422 RFC 2047, DOI 10.17487/RFC2047, November 1996, 2423 . 2425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2426 Requirement Levels", BCP 14, RFC 2119, 2427 DOI 10.17487/RFC2119, March 1997, 2428 . 2430 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2431 Thayer, "OpenPGP Message Format", RFC 4880, 2432 DOI 10.17487/RFC4880, November 2007, 2433 . 2435 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2436 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2437 May 2017, . 2439 18.2. Informative References 2441 [Attested-Certifications] 2442 "Documentation of the Attested Certifications subpacket", 2443 n.d., . 2446 [AUTOCRYPT] 2447 Breitmoser, V., Krekel, H., and D. K. Gillmor, "Autocrypt 2448 - Convenient End-to-End Encryption for E-Mail", n.d., 2449 . 2451 [BITCOIN] "Bitcoin", n.d., . 2453 [CONIKS] Felten, E., Freedman, M., Melara, M., Blankstein, A., and 2454 J. Bonneau, "CONIKS Key Management System", n.d., 2455 . 2457 [DEBIAN-KEYRING] 2458 McDowell, J., "Debian Keyring", n.d., 2459 . 2461 [GnuPG] Koch, W., "Using the GNU Privacy Guard", 4 April 2019, 2462 . 2464 [I-D.koch-openpgp-webkey-service] 2465 Koch, W., "OpenPGP Web Key Directory", Work in Progress, 2466 Internet-Draft, draft-koch-openpgp-webkey-service-13, 14 2467 November 2021, . 2470 [I-D.mccain-keylist] 2471 McCain, R. M., Lee, M., and N. Welch, "Distributing 2472 OpenPGP Key Fingerprints with Signed Keylist 2473 Subscriptions", Work in Progress, Internet-Draft, draft- 2474 mccain-keylist-05, 2 September 2019, 2475 . 2478 [I-D.shaw-openpgp-hkp] 2479 Shaw, D., "The OpenPGP HTTP Keyserver Protocol (HKP)", 2480 Work in Progress, Internet-Draft, draft-shaw-openpgp-hkp- 2481 00, 20 March 2003, . 2484 [KEY-TRANSPARENCY] 2485 Belvin, G. and R. Hurst, "Key Transparency, a transparent 2486 and secure way to look up public keys", n.d., 2487 . 2489 [MAILVELOPE-KEYSERVER] 2490 Oberndörfer, T., "Mailvelope Keyserver", n.d., 2491 . 2493 [MONKEYSPHERE] 2494 Gillmor, D. K. and J. Rollins, "Monkeysphere", n.d., 2495 . 2497 [PARCIMONIE] 2498 Intrigeri, "Parcimonie", n.d., 2499 . 2502 [PGP-GLOBAL-DIRECTORY] 2503 Symantec Corporation, "PGP Global Directory Key 2504 Verification Policy", 2011, 2505 . 2508 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 2509 and T. Wright, "Transport Layer Security (TLS) 2510 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 2511 . 2513 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2514 DOI 10.17487/RFC5322, October 2008, 2515 . 2517 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 2518 Galperin, S., and C. Adams, "X.509 Internet Public Key 2519 Infrastructure Online Certificate Status Protocol - OCSP", 2520 RFC 6960, DOI 10.17487/RFC6960, June 2013, 2521 . 2523 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 2524 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 2525 . 2527 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 2528 (DANE) Bindings for OpenPGP", RFC 7929, 2529 DOI 10.17487/RFC7929, August 2016, 2530 . 2532 [SKS] Minsky, Y., Fiskerstrand, K., and P. Pennock, "SKS 2533 Keyserver Documentation", 25 March 2018, 2534 . 2537 [TOR] "The Tor Project", n.d., . 2539 [UNICODE-NORMALIZATION] 2540 Whistler, K., "Unicode Normalization Forms", 4 February 2541 2019, . 2543 Author's Address 2545 Daniel Kahn Gillmor 2546 American Civil Liberties Union 2547 125 Broad St. 2548 New York, NY, 10004 2549 United States of America 2550 Email: dkg@fifthhorseman.net