idnits 2.17.00 (12 Aug 2021) /tmp/idnits17374/draft-dkg-openpgp-abuse-resistant-keystore-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 354 has weird spacing: '...ct (by remov...' == Line 357 has weird spacing: '..., this remov...' == Line 358 has weird spacing: '... any signat...' == Line 359 has weird spacing: '...revoked signa...' -- The document date (April 04, 2019) is 1143 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 695 -- Looks like a reference, but probably isn't: '2' on line 697 == Outdated reference: A later version (-10) exists of draft-ietf-openpgp-rfc4880bis-06 == Outdated reference: A later version (-14) exists of draft-koch-openpgp-webkey-service-07 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 openpgp D. Gillmor 3 Internet-Draft ACLU 4 Intended status: Informational April 04, 2019 5 Expires: October 6, 2019 7 Abuse-Resistant OpenPGP Keystores 8 draft-dkg-openpgp-abuse-resistant-keystore-00 10 Abstract 12 OpenPGP transferable public keys are composite certificates, made up 13 of primary keys, user IDs, identity certifications ("signature 14 packets"), subkeys, and so on. They are often assembled by merging 15 multiple certificates that all share the same primary key, and 16 distributed in public keystores. 18 Unfortunately, since any third-party can add certifications with any 19 content to any OpenPGP certificate, the assembled/merged form of a 20 certificate can become unwieldy or undistributable. 22 This draft documents techniques that an archive of OpenPGP 23 certificates can use to mitigate the impact of these third-party 24 certificate flooding attacks. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 6, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Simple Mitigations . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. Limited Packet Sizes . . . . . . . . . . . . . . . . . . 6 66 3.2. Strict User IDs . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. Drop or Standardize Unhashed Subpackets . . . . . . . . . 6 68 3.4. Drop User Attributes . . . . . . . . . . . . . . . . . . 7 69 3.5. Drop Non-exportable Certifications . . . . . . . . . . . 7 70 3.6. Accept Only Cryptographically-verifiable Certifications . 7 71 3.7. Accept Only Profiled Certifications . . . . . . . . . . . 7 72 4. Contextual Mitigations . . . . . . . . . . . . . . . . . . . 8 73 4.1. Drop Superseded Signatures . . . . . . . . . . . . . . . 8 74 4.2. Drop Expired Signatures . . . . . . . . . . . . . . . . . 8 75 4.3. Drop Dangling User IDs, User Attributes, and Subkeys . . 9 76 4.4. Drop All Other Elements of a Directly-Revoked Certificate 9 77 4.5. Implicit Expiration Date . . . . . . . . . . . . . . . . 10 78 5. First-party-only Keystores . . . . . . . . . . . . . . . . . 10 79 6. First-party-attested Third-party Certifications . . . . . . . 11 80 6.1. Key Server Preferences "No-modify" . . . . . . . . . . . 12 81 6.2. Client Interactions . . . . . . . . . . . . . . . . . . . 12 82 7. Side Effects and Ecosystem Impacts . . . . . . . . . . . . . 12 83 7.1. Designated Revoker . . . . . . . . . . . . . . . . . . . 12 84 7.2. Certification-capable Subkeys . . . . . . . . . . . . . . 12 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 87 10. User Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 12. Document Considerations . . . . . . . . . . . . . . . . . . . 14 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 92 13.2. Informative References . . . . . . . . . . . . . . . . . 15 93 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 96 1. Introduction 98 1.1. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 1.2. Terminology 108 o "OpenPGP certificate" (or just "certificate") is used 109 interchangeably with [RFC4880]'s "Transferable Public Key". The 110 term "certificate" refers unambiguously to the entire composite 111 object, unlike "key", which might also be used to refer to a 112 primary key or subkey. 114 o An "identity certification" (or just "certification") is an 115 [RFC4880] signature packet that covers OpenPGP identity 116 information - that is, any signature packet of type 0x10, 0x11, 117 0x12, or 0x13. Certifications are said to (try to) "bind" a 118 primary key to a User ID. 120 o The primary key that makes the certification is known as the 121 "issuer". The primary key over which the certification is made is 122 known as the "subject". 124 o A "first-party certification" is issued by the primary key of a 125 certificate, and binds itself to a user ID in the certificate. 126 That is, the issuer is the same as the subject. This is sometimes 127 referred to as a "self-sig". 129 o A "third-party certification" is a made over a primary key and 130 user ID by some other certification-capable primary key. That is, 131 the issuer is different than the subject. (The elusive "second- 132 party" is presumed to be the verifier who is trying to interpret 133 the certificate) 135 o A "keystore" is any collection of OpenPGP certificates. Keystores 136 typically receive mergeable updates over the course of their 137 lifetime which might add to the set of OpenPGP certificates they 138 hold, or update the certificates. 140 o "Certificate discovery" is the process whereby a user retrieves an 141 OpenPGP certificate based on user ID. A user attempting to 142 discover a certificate from a keystore will search for a substring 143 of the known user IDs, most typically an e-mail address if the 144 user ID is an [RFC5322] name-addr or addr-spec. Some certificate 145 discovery mechanisms look for an exact match on the known user 146 IDs. [I-D.koch-openpgp-webkey-service] and [I-D.shaw-openpgp-hkp] 147 are both certificate discovery mechanisms. 149 o "Certificate validation" is the process whereby a user decides 150 whether a given user ID in an OpenPGP certificate is acceptable. 151 For example, if the certificate has a user ID of "Alice 152 alice@example.org [1]" and the user wants to send an e-mail to 153 alice@example.org, the mail user agent might want to ensure that 154 the certificate is valid for this e-mail address before encrypting 155 to it. This process can take different forms, and can consider 156 many different factors, some of which are not directly contained 157 in the certificate itself. For example, certificate validation 158 might consider whether the certificate was fetched via DANE 159 ([RFC7929]) or WKD ([I-D.koch-openpgp-webkey-service]); or whether 160 it has seen e-mails from that address signed by the certificate in 161 the past; or how long it has known about certificate. 163 o "Certificate update" is the process whereby a user fetches new 164 information about a certificate, potentially merging those OpnePGP 165 packets to change the status of the certificate. Updates might 166 include adding or revoking user IDs or subkeys, updating 167 expiration dates, or even revoking the entire certificate by 168 revoking the primary key directly. A user attempting to update a 169 certificate typically queries a keystore based on the 170 certificate's fingerprint. 172 o A "keyserver" is a particular kind of keystore, typically means of 173 publicly distributing OpenPGP certificates or updates to them. 174 Examples of keyserver software include [SKS] and 175 [MAILVELOPE-KEYSERVER]. One common HTTP interface for keyservers 176 is [I-D.shaw-openpgp-hkp]. 178 o A "synchronizing keyserver" is a keyserver which gossips with 179 other peers, and typically acts as an append-only log. Such a 180 keyserver is typically useful for certificate discovery, 181 certificate updates, and revocation information. They are 182 typically _not_ useful for certificate validation, since they make 183 no assertions about whether the identities in the certificates 184 they server are accurate. As of the writing of this document, 185 [SKS] is the canonical synchronizing keyserver implementation, 186 though other implementations exist. 188 o An "e-mail-validating keyserver" is a keyserver which attempts to 189 verify the identity in an OpenPGP certificate's user ID by 190 confirming access to the e-mail account, and possibly by 191 confirming access to the secret key. Some implementations permit 192 removal of a certificate by anyone who can prove access to the 193 e-mail address in question. They are useful for certificate 194 discovery based on e-mail address and certificate validation (by 195 users who trust the operator), but some may not be useful for 196 certificate update or revocation, since a certificate could be 197 simply replaced by an adversary who also has access to the e-mail 198 address in question. [MAILVELOPE-KEYSERVER] is an example of such 199 a keyserver. 201 o "Cryptographic validity" refers to mathematical evidence that a 202 signature came from the secret key associated with the public key 203 it claims to come from. Note that a certification may be 204 cryptographically valid without the signed data being true (for 205 example, a given certificate with the user ID "Alice 206 alice@example.org [2]" might not belong to the person who controls 207 the e-mail address "alice@example.org" even though the self-sig is 208 cryptographically valid). In particular, cryptographic validity 209 for user ID in a certificate is typically insufficient evidence 210 for certificate validation. Also note that knowledge of the 211 public key of the issuer is necessary to determine whether any 212 given signature is cryptographically valid. Some keyservers 213 perform cryptographic validation in some contexts. Other 214 keyservers (like [SKS]) perform no cryptographic validation 215 whatsoever. 217 2. Problem Statement 219 Many public keystores (including both the [SKS] keyserver network and 220 [MAILVELOPE-KEYSERVER]) allow anyone to attach arbitrary data (in the 221 form of third-party certifications) to any certificate, bloating that 222 certificate to the point of being impossible to effectively retrieve. 223 For example, some OpenPGP implementations simply refuse to process 224 certificates larger than a certain size. 226 This kind of Denial-of-Service attack makes it possible to make 227 someone else's certificate unretrievable from the keystore, 228 preventing certificate discovery. It also makes it possible to swamp 229 a certificate that has been revoked, preventing certificate update, 230 potentially leaving the client of the keystore with the compromised 231 certificate in an unrevoked state locally. 233 Additionally, even without malice, OpenPGP certificates can 234 potentially grow without bound. 236 The rest of this document describes some mitigations that can be used 237 by keystores that are concerned about these problems but want to 238 continue to offer some level of service for certificate discovery, 239 certificate update, or certificate validation. 241 3. Simple Mitigations 243 These steps can be taken by any keystore that wants to avoid 244 obviously malicious abuse. They can be implemented on receipt of any 245 new packet, and are based strictly on the structure of the packet 246 itself. 248 3.1. Limited Packet Sizes 250 While [RFC4880] permits OpenPGP packet sizes of arbitrary length, 251 OpenPGP certificates rarely need to be so large. An abuse-resistant 252 keystore SHOULD reject any OpenPGP packet larger than 8383 octets. 253 (This cutoff is chosen because it guarantees that the packet size can 254 be represented as a one- or two-octet [RFC4880] "New Format Packet 255 Length", but it could be reduced further) 257 This may cause problems for user attribute packets that contain large 258 images, but it's not clear that these images are concretely useful in 259 any context. Some keystores MAY extend this limit for user attribute 260 packets specifically, but SHOULD NOT allow even user attributes 261 packets larger than 65536 octets. 263 3.2. Strict User IDs 265 [RFC4880] indicates that User IDs are expected to be UTF-8 strings. 266 An abuse-resistant keystore MUST reject any user ID that is not valid 267 UTF-8. 269 Some abuse-resistant keystores MAY only accept User IDs that meet 270 even stricter conventions, such as an [RFC5322] name-addr or addr- 271 spec, or a URL like "ssh://host.example.org". 273 As simple text strings, User IDs don't need to be nearly as long as 274 any other packets. An abuse-resistant keystore SHOULD reject any 275 user ID packet larger than 1024 octets. 277 3.3. Drop or Standardize Unhashed Subpackets 279 [RFC4880] signature packets contain an "unhashed" block of 280 subpackets. These subpackets are not covered by any cryptographic 281 signature, so they are ripe for abuse. 283 An abuse-resistant keysetore SHOULD strip out all unhashed 284 subpackets. 286 Note that some certifications only identify the issuer of the 287 certification by an unhashed Issuer ID subpacket. If a 288 certification's hashed subpacket section has no Issuer ID or Issuer 289 Fingerprint (see [I-D.ietf-openpgp-rfc4880bis]) subpacket, then an 290 abuse-resistant keystore that has cryptographically validated the 291 certification SHOULD make the unhashed subpackets contain only a 292 single subpacket. That subpacket should be of type Issuer 293 Fingerprint, and should contain the fingerprint of the issuer. 295 A special exception may be made for unhashed subpackets in a third- 296 party certification that contain attestations from the certificate's 297 primary key as described in Section 6. 299 3.4. Drop User Attributes 301 Due to size concerns, some abuse-resistant keystores MAY choose to 302 ignore user attribute packets entirely, as well as any certifications 303 that cover them. 305 3.5. Drop Non-exportable Certifications 307 An abuse-resistant keystore MUST NOT accept any certification that 308 has the "Exportable Certification" subpacket present and set to 0. 309 While most keystore clients will not upload these "local" 310 certifications anyway, a reasonable public keystore that wants to 311 minimize data has no business storing or distributing these 312 certifications. 314 3.6. Accept Only Cryptographically-verifiable Certifications 316 An abuse-resistant keystore that is capable of doing cryptographic 317 validation MAY decide to reject certifications that it cannot 318 cryptographically validate. 320 This may mean that the keystore rejects some packets while it is 321 unaware of the public key of the issuer of the packet. 323 3.7. Accept Only Profiled Certifications 325 An aggressively abuse-resistant keystore MAY decide to only accept 326 certifications that meet a specific profile. For example, it MAY 327 reject certifications with unknown subpacket types, unknown 328 notations, or certain combinations of subpackets. This can help to 329 minimize the amount of room for garbage data uploads. 331 Any abuse-resistant keystore that adopts such a strict posture should 332 clearly document what its expected certificate profile is, and should 333 have a plan for how to extend the profile if new types of 334 certification appear that it wants to be able to distribute. 336 4. Contextual Mitigations 338 The following mitigations may cause some packets to be dropped after 339 the keystore receives new information, or as time passes. This is 340 entirely reasonable for some keystores, but it may be surprising for 341 any keystore that expects to be append-only (for example, some 342 keyserver synchronization techniques may expect this property to 343 hold). 345 Note also that many of these mitigations depend on cryptographic 346 validation. 348 A keystore that needs to be append-only, or which cannot perform 349 cryptographic validation MAY omit these mitigations. 351 Note that [GnuPG] anticipates some of these suggestions with its 352 "clean" subcommand, which is documented as: 354 Compact (by removing all signatures except the selfsig) 355 any user ID that is no longer usable (e.g. revoked, or 356 expired). Then, remove any signatures that are not usable 357 by the trust calculations. Specifically, this removes 358 any signature that does not validate, any signature that 359 is superseded by a later signature, revoked signatures, 360 and signatures issued by keys that are not present on the 361 keyring. 363 4.1. Drop Superseded Signatures 365 An abuse-resistant keystore SHOULD drop all signature packets that 366 are explicitly superseded. For example, there's no reason to retain 367 or distribute a self-sig by key K over User ID U from 2017 if the 368 keystore have a cryptographically-valid self-sig over from 369 2019. 371 Note that this covers both certifications and signatures over 372 subkeys, as both of these kinds of signature packets may be 373 superseded. 375 Getting this right requires a nuanced understanding of subtleties in 376 [RFC4880] related to timing and revocation. 378 4.2. Drop Expired Signatures 380 If a signature packet is known to only be valid in the past, there is 381 no reason to distribute it further. An abuse-resistant keystore with 382 access to a functionally real-time clock SHOULD drop all 383 certifications and subkey signature packets with an expiration date 384 in the past. 386 Note that this assumes that the keystore and its clients all have 387 roughly-synchronized clocks. If that is not the case, then there 388 will be many other problems! 390 4.3. Drop Dangling User IDs, User Attributes, and Subkeys 392 If enough signature packets are dropped, it's possible that some of 393 the things that those signature packets cover are no longer valid. 395 An abuse-resistant keystore which has dropped all certifications that 396 cover a User ID SHOULD also drop the User ID packet. 398 Note that a User ID that becomes invalid due to revocation MUST NOT 399 be dropped, because the User ID's revocation signature itself remains 400 valid, and needs to be distributed. 402 A primary key with no User IDs and no subkeys and no revocations MAY 403 itself also be removed from distribution, though note that the 404 removal of a primary key may make it impossible to cryptographically 405 validate other certifications held by the keystore. 407 4.4. Drop All Other Elements of a Directly-Revoked Certificate 409 If the primary key of a certiifcate is revoked via a direct key 410 signature, an abuse-resistant keystore SHOULD drop all the rest of 411 the associated data (user IDs, user attributes, and subkeys, and all 412 attendant certifications and subkey signatures). This defends 413 against an adversary who compromises a primary key and tries to flood 414 the certificate to hide the revocation. 416 Note that the direct key revocation signature MUST NOT be dropped. 418 In the event that an abuse-resistant keystore is flooded with direct 419 key revocation signatures, it should retain the strongest, earliest 420 revocation. 422 In particular, if any of the revocation signatures has a "Reason for 423 Revocation" of "Key material has been compromised", the keystore 424 SHOULD retain the earliest such revocation signature (by signature 425 creation date). 427 If none have "Key material has been compromised", but some have "No 428 reason specified", or lack a "Reason for Revocation" entirely, then 429 the keystore SHOULD retain the earliest such revocation signature. 431 Otherwise, the abuse-resistant keystore SHOULD retain the earliest 432 direct key revocation signature it has seen. 434 If any of the date comparisons results in a tie between two 435 revocation signatures of the same severity, an abuse-resistant 436 keystore SHOULD retain the signature that sorts earliest based on a 437 binary string comparison of the signature packet itself. 439 4.5. Implicit Expiration Date 441 A particularly aggressive abuse-resistant keystore MAY choose an 442 implicit expiration date for all signature packets. For example, a 443 signature packet that claims no expiration could be treated by the 444 keystore as expiring 3 years after issuance. 446 FIXME: it's not clear what should happen with signature packets 447 marked with an explicit expiration that is longer than implicit 448 maximum. Should it be capped to the implicit date, or accepted? 450 Warning: This idea is pretty radical, and it's not clear what it 451 would do to an ecosystem that depends on such a keystore. It 452 probably needs more thinking. 454 5. First-party-only Keystores 456 In addition to all of the mitigations above, some keystores may 457 resist abuse by declining to carry third-party certifications 458 entirely. 460 A first-party-only keystore _only_ accepts and distributes 461 cryptographically-valid first-party certifications. Given a primary 462 key that the keystore understands, it will only attach user IDs that 463 have a valid self-sig, and will only accept and re-distribute subkeys 464 that are also cryptographically valid (including requiring cross-sigs 465 for signing-capable subkeys as recommended in [RFC4880]). 467 This effectively solves the problem of abusive bloating attacks on 468 any certificate, because the only party who can make a certificate 469 overly large is the holder of the secret corresponding to the primary 470 key itself. 472 However, first-party-only keystores also introduce new problems, for 473 those people who rely on the keystore for discovery of third-party 474 certifications. Section 6 attempts to address this lack. 476 6. First-party-attested Third-party Certifications 478 We can augment a first-party-only keystore to allow it to distribute 479 third-party certifications as long as the first-party has signed off 480 on the specific third-party certification. 482 An abuse-resistant keystore SHOULD only accept a third-party 483 certification if it meets the following criteria: 485 o The third-party certification MUST be cryptographically valid. 486 Note that this means that the keystore needs to know the primary 487 key for the issuer of the third-party certification. 489 o The third-party certification MUST have an unhashed subpacket of 490 type Embedded Signature, the contents of which we'll call the 491 "attestation". This attestation is from the certificate's primary 492 key over the third-party certification itself, as detailed in the 493 steps below: 495 o The attestation MUST be an OpenPGP signature packet of type 0x50 496 (Third-Party Confirmation signature) 498 o The attestation MUST contain a notation subpacket 500 o The attestation MUST contain a hashed "Issuer Fingerprint" 501 subpacket with the fingerprint of the primary key of the 502 certificate in question. 504 o The attestation MUST NOT be marked as non-exportable. 506 o The attestation MUST contain a hashed Notation subpacket with the 507 name "ksok", and an empty (0-octet) value. 509 o The attestation MUST contain a hashed "Signature Target" subpacket 510 with "public-key algorithm" that matches the public-key algorithm 511 of the third-party certification. 513 o The attestation's hashed "Signature Target" subpacket MUST use a 514 reasonably strong hash algorithm (as of this writing, any 515 [RFC4880] hash algorithm except MD5, SHA1, or RIPEMD160), and MUST 516 have a hash value equal to the hash over the third-party 517 certification with all unhashed subpackets removed. 519 o The attestation MUST be cryptographically valid, verifiable by the 520 primary key of the certificate in question. 522 What this means is that a third-party certificate will only be 523 accepted/distributed by the keystore if: 525 o the keystore knows about both the first- and third-parties. 527 o the third-party has made the identity assertion 529 o the first-party has confirmed that they're OK with the third-party 530 certification being distributed by any keystore. 532 FIXME: it's not clear whether the "ksok" notification is necessary - 533 it's in place to avoid some accidental confusion with any other use 534 of the Third-Party Confirmation signature packet type, but the author 535 does not know of any such use that might collide. 537 6.1. Key Server Preferences "No-modify" 539 [RFC4880] section 5.2.3.17 ("Key Server Preferences") defines a "No- 540 modify" bit. That bit has never been respected by any keyserver 541 implementation that the author is aware of. This section effectively 542 asks an abuse-resistant keystore to treat that bit as always set, 543 whether it is present in the certificate or not. 545 6.2. Client Interactions 547 The multi-stage layer of creating such an attestation (certificate 548 creation by the first-party, certification by the third-party, 549 attestation by the first-party, then handoff to the keystore) may 550 represent a usability obstacle to a user who needs a third-party- 551 certified OpenPGP certificate. 553 No current OpenPGP client can easily create the attestions described 554 in this section. More implementation work needs to be done to make 555 it easy (and understandable) for a user to perform this kind of 556 attestation. 558 7. Side Effects and Ecosystem Impacts 560 7.1. Designated Revoker 562 A first-party-only keystore might decline to distribute revocations 563 made by the designated revoker. This is a risk to certificate-holder 564 who depend on this mechanism. Perhaps this document should be 565 amended to include these 567 7.2. Certification-capable Subkeys 569 Much of this discussion assumes that primary keys are the only 570 certification-capable keys in the OpenPGP ecosystem. Some proposals 571 have been put forward that assume that subkeys can be marked as 572 certification-capable. If subkeys are certification-capable, then 573 much of the reasoning in this draft becomes much more complex, as 574 subkeys themselves can be revoked by their primary key without 575 invalidating the key material itself. That is, a subkey can be both 576 valid (in one context) and invalid (in another context) at the same 577 time. So questions about what data can be dropped are much fuzzier. 579 The author of this draft recommends _not_ considering any subkeys to 580 be certification-capable to avoid this headache. 582 8. Security Considerations 584 These mitigations defend individual OpenPGP certificates against 585 bloating attacks. They collectively reduce the amount of data that 586 such a keystore needs to track over time, but given the near-infinite 587 space of possible OpenPGP keys that can be generated, the keystore in 588 aggregate can still be made to grow without bound. This document 589 proposes no clear measures to defend against such a denial of service 590 attack against the keystore itself. 592 Section 7.1 describes a potentially 594 TODO (more security considerations) 596 9. Privacy Considerations 598 Public OpenPGP keystores often distribute names or e-mail addresses 599 of people. Some people do not want their names or e-mail addresses 600 distributed in a public keystore, or may change their minds about it 601 at some point. Append-only keystores are particularly problematic in 602 that regard. The mitigation in Section 4.4 can help such users strip 603 their details from keys that they control. However, if an OpenPGP 604 certificate with their details is uploaded to a keystore, but is not 605 under their control, it's unclear what mechanisms can be used to 606 remove the certificate that couldn't also be exploited to take down 607 an otherwise valid certificate. 609 Third-party certifications effectively map out some sort of social 610 graph. While the certifications basically only assert a binding 611 between user IDs, the parties those user IDs represent in the real 612 world, and cryptographic key material, those connections may be 613 potentially sensitive, and users may not want to see these maps 614 built. 616 TODO (more privacy considerations) 618 10. User Considerations 620 Section 6.2 describes some outstanding work that needs to be done to 621 help users understand how to produce and distribute a third-party- 622 certified OpenPGP certificate to an abuse-resistant keystore. 624 11. IANA Considerations 626 This document asks IANA to register the "ksok" notation name in the 627 OpenPGP Notation IETF namespace, with a reference to this document, 628 as defined in Section 6. 630 12. Document Considerations 632 [ RFC Editor: please remove this section before publication ] 634 This document is currently edited as markdown. Minor editorial 635 changes can be suggested via merge requests at 636 https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore or by 637 e-mail to the author. Please direct all significant commentary to 638 the public IETF OpenPGP mailing list: openpgp@ietf.org 640 13. References 642 13.1. Normative References 644 [I-D.ietf-openpgp-rfc4880bis] 645 Koch, W., carlson, b., Tse, R., and D. Atkins, "OpenPGP 646 Message Format", draft-ietf-openpgp-rfc4880bis-06 (work in 647 progress), November 2018. 649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", BCP 14, RFC 2119, 651 DOI 10.17487/RFC2119, March 1997, 652 . 654 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 655 Thayer, "OpenPGP Message Format", RFC 4880, 656 DOI 10.17487/RFC4880, November 2007, 657 . 659 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 660 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 661 May 2017, . 663 13.2. Informative References 665 [GnuPG] Koch, W., "Using the GNU Privacy Guard", n.d., 666 . 668 [I-D.koch-openpgp-webkey-service] 669 Koch, W., "OpenPGP Web Key Directory", draft-koch-openpgp- 670 webkey-service-07 (work in progress), November 2018. 672 [I-D.shaw-openpgp-hkp] 673 Shaw, D., "The OpenPGP HTTP Keyserver Protocol (HKP)", 674 draft-shaw-openpgp-hkp-00 (work in progress), March 2003. 676 [MAILVELOPE-KEYSERVER] 677 Oberndoerfer, T., "Mailvelope Keyserver", n.d., 678 . 680 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 681 DOI 10.17487/RFC5322, October 2008, 682 . 684 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 685 (DANE) Bindings for OpenPGP", RFC 7929, 686 DOI 10.17487/RFC7929, August 2016, 687 . 689 [SKS] Pennock, P., "SKS Keyserver Documentation", March 2018, 690 . 693 13.3. URIs 695 [1] mailto:alice@example.org 697 [2] mailto:alice@example.org 699 Author's Address 701 Daniel Kahn Gillmor 702 American Civil Liberties Union 703 125 Broad St. 704 New York, NY 10004 705 USA 707 Email: dkg@fifthhorseman.net