idnits 2.17.1 draft-mccain-keylist-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: ---------------------------------------------------------------------------- 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 -- The document date (September 2, 2019) is 1692 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 450 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Experimental RFC: RFC 7929 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. McCain 3 Internet-Draft FLM 4 Intended status: Standards Track M. Lee 5 Expires: March 5, 2020 TI 6 N. Welch 7 Google 8 September 2, 2019 10 Distributing OpenPGP Key Fingerprints with Signed Keylist Subscriptions 11 draft-mccain-keylist-05 13 Abstract 15 This document specifies a system by which an OpenPGP client may 16 subscribe to an organization's public keylist to keep its keystore 17 up-to-date with correct keys from the correct keyserver(s), even in 18 cases where the keys correspond to multiple (potentially 19 uncontrolled) domains. Ensuring that all members or followers of an 20 organization have their colleagues' most recent PGP public keys is 21 critical to maintaining operational security. Without the most 22 recent keys' fingerprints and a source of trust for those keys (as 23 this document specifies), users must manually update and sign each 24 others' keys -- a system that is untenable in larger organizations. 25 This document proposes a experimental format for the keylist file as 26 well as requirements for clients who wish to implement this 27 experimental keylist subscription functionality. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 5, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.3. Note to Readers . . . . . . . . . . . . . . . . . . . . . 3 67 2. Functions and Procedures . . . . . . . . . . . . . . . . . . 4 68 2.1. Subscribing to Keylists . . . . . . . . . . . . . . . . . 4 69 2.2. Automatic Updates . . . . . . . . . . . . . . . . . . . . 4 70 2.3. Cryptographic Verification of Keylists . . . . . . . . . 6 71 3. Data Element Formats . . . . . . . . . . . . . . . . . . . . 6 72 3.1. Keylist . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.2. Signature . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.3. Well-Known URL . . . . . . . . . . . . . . . . . . . . . 8 75 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 76 5. Security Benefits . . . . . . . . . . . . . . . . . . . . . . 8 77 6. Relation to Other Technologies . . . . . . . . . . . . . . . 8 78 6.1. Web Key Directories . . . . . . . . . . . . . . . . . . . 9 79 6.2. OPENPGPKEY DNS Records . . . . . . . . . . . . . . . . . 9 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 84 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 87 1. Introduction 89 This document specifies a system by which clients may subscribe to 90 cryptographically signed 'keylists' of public key fingerprints. The 91 public keys do not necesssarily all correspond to a single domain. 92 This system enhances operational security by allowing seamless key 93 rotation across entire organizations without centralized public key 94 hosting. To enable cross-client compatibility, this document 95 provides a experimental format for the keylist, its cryptographic 96 verification, and the method by which it is retreived by the client. 97 The user interface by which a client provides this functionality to 98 the user is out of scope, as is the process by which the client 99 retrieves public keys. Other non-security-related implementation 100 details are also out of scope. 102 1.1. Requirements Notation 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119] . 108 1.2. Terminology 110 This document uses the terms "OpenPGP", "public key", "private key", 111 "signature", and "fingerprint" as defined by OpenPGP Message Format 112 [RFC4880] (the fingerprint type SHOULD be V4). 114 The term "keylist" is defined as a list of OpenPGP public key 115 fingerprints accessible via a URI in the format specified in 116 Section 3. Keylists SHOULD be treated as public documents, however a 117 system administrator MAY choose, for example, to restrict access to a 118 keylist to a specific subnet or private network. 120 An "authority key" is defined as the OpenPGP secret key used to sign 121 a particular keylist. Every keylist has a corresponding authority 122 key, and every authority key has at least one corresponding keylist. 123 A single authority key SHOULD NOT be used to sign multiple keylists. 125 To be "subscribed" to a keylist means that a program will retreive 126 that keylist on a regular interval. After retrieval, that program 127 will perform an update to an internal OpenPGP keystore. 129 A "client" is a program that allows the user to subscribe to 130 keylists. A client may be an OpenPGP client itself or a separate 131 program that interfaces with an OpenPGP client to update its 132 keystore. 134 1.3. Note to Readers 136 RFC Editor: please remove this section prior to publication. 138 Development of this Internet draft takes place on GitHub at 139 firstlookmedia/Keylist-RFC [1]. 141 We are still considering whether this Draft is better for the 142 Experimental or Informational track. All feedback is appreciated. 144 2. Functions and Procedures 146 As new keys are created and other keys are revoked, it is critical 147 that all members of an organization have the most recent set of keys 148 available on their computers. Keylists enable organizations to 149 publish a directory of OpenPGP keys that clients can use to keep 150 their internal keystores up-to-date. 152 2.1. Subscribing to Keylists 154 A single client may subscribe to any number of keylists. When a 155 client first subscribes to a keylist, it SHOULD update or import 156 every key present in the keylist into its local keystore. Keylist 157 subscriptions SHOULD be persistent -- that is, they should be 158 permanently stored by the client to enable future automatic updates. 160 To subscribe to a keylist, the client must be aware of the keylist 161 URI (see [RFC3986]), and the fingerprint of the authority key used to 162 sign the keylist. The protocol used to retrieve the keylist and its 163 signature SHOULD be HTTPS (see [RFC2818]), however other 164 implementation MAY be supported. A client implementing keylist 165 functionality MUST support the retrieval of keylists and signatures 166 over HTTPS. All other protocols are OPTIONAL. 168 A client MUST NOT employ a trust-on-first-use (TOFU) model for 169 determining the fingerprint of the authority public key; the 170 authority public key fingerprint must be explicitly provided by the 171 user. 173 The process by which the client stores its keylist subscriptions is 174 out of scope, as is the means by which subscription functionality is 175 exposed to the end-user. 177 The client MAY provide the option to perform all its network activity 178 over a SOCKS5 proxy (see [RFC1928]). 180 2.2. Automatic Updates 182 The primary purpose of keylists is to enable periodic updates of 183 OpenPGP clients' internal keystores. We RECOMMEND that clients 184 provide automatic 'background' update functionality; we also regonize 185 that automatic background updates are not possible in every 186 application (specifically cross-platform CLI tools). 188 When automatic background updates are provided, we RECOMMEND that 189 clients provide a default refresh interval of less than one day, 190 however we also RECOMMEND that clients allow the user to select this 191 interval. The exact time at which updates are performed is not 192 critical. 194 To perform an update, the client MUST perform the following steps on 195 each keylist to which it is subscribed. The steps SHOULD be 196 performed in the given order. 198 1. Obtain a current copy of the keylist from its URI. If a current 199 copy (i.e. not from local cache) cannot be obtained, the client 200 SHOULD abort the update for this keylist and notify the user. 201 The client SHOULD continue the update for other keylists to which 202 it is subscribed, notwithstanding also failing the criteria 203 described in this section. 205 2. Obtain a current copy of the keylist's signature data from its 206 URI, which is included in the keylist data format specified in 207 Section 3. If a current copy cannot be obtained, the client 208 SHOULD abort the update and notify the user. The client SHOULD 209 continue the update for other keylists to which it is subscribed, 210 notwithstanding also failing the criteria described in this 211 section. 213 3. Using the keylist and the keylist's signature, cryptographically 214 verify that the keylist was signed using the authority key. If 215 the signature does not verify, the client MUST abort the update 216 of this keylist and SHOULD alert the user. The client SHOULD NOT 217 abort the update of other keylists to which it is subscribed, 218 unless they too fail signature verification. 220 4. Validate the format of the keylist according to Section 3 . If 221 the keylist is in an invalid format, the client MUST abort the 222 update this keylist and SHOULD alert the user. The client SHOULD 223 continue the update for other keylists to which it is subscribed, 224 notwithstanding also failing the criteria described in this 225 section. 227 5. For each fingerprint listed in the keyfile, if a copy of the 228 associated public key is not present in the client's local 229 keystore, retrieve it from the keyserver specified by either the 230 key entry, the keylist (see Section 3) or, if the keylist 231 specifies no keyserver, from the user's default keyserver. If 232 the public key cannot be found for a particular fingerprint, the 233 client MUST NOT abort the entire update process; instead, it 234 SHOULD notify the user that the key retrieval failed but 235 otherwise merely skip updating the key and continue. If the key 236 is already present and not revoked, refresh it from the keyserver 237 determined in the same manner as above. If it is present and 238 revoked, do nothing for that particular key. 240 2.3. Cryptographic Verification of Keylists 242 To ensure authenticity of a keylist during an update, the client MUST 243 verify that the keylist's data matches its cryptographic signature, 244 and that the public key used to verify the signature matches the 245 authority key fingerprint given by the user. 247 For enhanced security, it is RECOMMENDED that keylist operators sign 248 each public key listed in their keylist with the authority private 249 key. This way, an organization can have an internal trust 250 relationship without requiring members of the organization to certify 251 each other's public keys. 253 3. Data Element Formats 255 The following are format specifications for the keylist file and its 256 signature file. 258 3.1. Keylist 260 The keylist MUST be a valid JavaScript Object Notation (JSON) Data 261 Interchange Format [RFC8259] object with specific keys and values, as 262 defined below. Note that unless otherwise specified, 'key' in this 263 section refers to JSON keys -- not OpenPGP keys. 265 To encode metadata, the keylist MUST have a "metadata" root key with 266 an object as the value ("metadata object"). The metadata object MUST 267 contain a "signature_uri" key whose value is the URI string of the 268 keylist's signature file. All metadata keys apart from 269 "signature_uri" are OPTIONAL. 271 The metadata object MAY contain a "keyserver" key with the value of 272 the URI string of a HKP keyserver from which the OpenPGP keys in the 273 keylist should be retrieved. Each PGP key listed in the keylist MAY 274 have a "keyserver" JSON key; if a PGP key in the keylist specifies a 275 HKP keyserver that is different from the one described in the 276 metadata object, the PGP key-specific keyserver should be used to 277 retrieve that particular key (and not the key listed in the metadata 278 object). 280 The metadata object MAY contain a "comment" key with the value of any 281 string. The metadata object MAY also contain other arbitrary key- 282 value pairs. 284 The keylist MUST have a "keys" key with an array as the value. This 285 array contains a list of OpenPGP key fingerprints and metadata about 286 them. Each item in the array MUST be an object. Each of these 287 objects MUST have a "fingerprint" key with the value of a string that 288 contains the full 40-character hexadecimal public key fingerprint, as 289 defined in OpenPGP Message Format [RFC4880] . Any number of space 290 characters (' ', U+0020) MAY be included at any location in the 291 fingerprint string. These objects MAY contain "name" (the name of 292 the PGP key's owner), "email" (an email of the PGP key's owner), 293 "keyserver" (a HKP keyserver from which the key should be retrieved), 294 and "comment" key-value pairs, as well as any other key-value pairs. 296 The following is an example of a valid keylist. 298 { 299 "metadata": { 300 "signature_uri": "https://www.example.com/keylist.json.asc", 301 "comment": "This is an example of a keylist file" 302 }, 303 "keys": [ 304 { 305 "fingerprint": "927F419D7EC82C2F149C1BD1403C2657CD994F73", 306 "name": "Micah Lee", 307 "email": "micah.lee@theintercept.com", 308 "comment": "Each key can have a comment" 309 }, 310 { 311 "fingerprint": "1326CB162C6921BF085F8459F3C78280DDBF52A1", 312 "name": "R. Miles McCain", 313 "email": "0@rmrm.io", 314 "keyserver": "https://keys.openpgp.org/" 315 }, 316 { 317 "fingerprint": "E0BE0804CF04A65C1FC64CC4CAD802E066046C02", 318 "name": "Nat Welch", 319 "email": "nat.welch@firstlook.org" 320 } 321 ] 322 } 324 3.2. Signature 326 The signature file MUST be an ASCII-armored 'detached signature' of 327 the keylist file, as defined in OpenPGP Message Format [RFC4880] . 329 3.3. Well-Known URL 331 Keylists SHOULD NOT be well-known resources [RFC4880]. To subscribe 332 to a keylist, the client must be aware not only of the keylist's 333 location, but also of the fingerprint of the authority public key 334 used to sign the keylist. Furthermore, because keylists can 335 reference public keys from several different domains, the expected 336 host of the well-known location for a keylist may not always be self- 337 evident. 339 4. Implementation Status 341 GPG Sync, an open source program created by one of the authors, 342 implements this experimental standard. GPG Sync is used by First 343 Look Media and the Freedom of the Press Foundation to keep OpenPGP 344 keys in sync across their organizations, as well as to publish their 345 employee's OpenPGP keys to the world. These organizations 346 collectively employ more than 200 people and have used the system 347 described in this document successfully for multiple years. 349 GPG Sync's existing code can be found at 350 352 First Look Media's keylist file can be found at 353 355 5. Security Benefits 357 The keylist subscription functionality defined in this document 358 provides a number of security benefits, including: 360 o The ability for new keys to be quickly distributed across an 361 organization. 363 o Removing the complexity of key distribution from end users, 364 allowing them to focus on the content of their communications 365 rather than on key management. 367 o The ability for an organization to prevent the spread of falsely 368 attributed keys by centralizing the public key discovery process 369 within their organization without centralized public key hosting. 371 6. Relation to Other Technologies 372 6.1. Web Key Directories 374 Unlike Web Key Directories, keylists are not domain specific. A 375 keylist might contain public key fingerprints for email addresses 376 across several different domains. Moreover, keylists only provide 377 references to public keys by way of fingerprints; Web Key Directories 378 provide the public keys themselves. 380 6.2. OPENPGPKEY DNS Records 382 A keylist MAY reference public keys corresponding to email addresses 383 across several different domains. Because managing OPENPGPKEY DNS 384 Records [RFC7929] for a particular domain requires control of that 385 domain, the OPENPGPKEY DNS Record system is not suitable for cases in 386 which keys are strewn about several different domains, including ones 387 outside of the control of an organization's system adminitrators. 389 7. Security Considerations 391 There is a situation in which keylist subscriptions could pose a 392 potential security threat. If both the authority key and the keylist 393 distribution system were to be compromised, it would be possible for 394 an attacker to distribute any key of their choosing to the 395 subscribers of the keylist. The potential consequences of this 396 attack are limited, however, because the attacker cannot remove or 397 modify the keys already present on subscribers' systems. 399 Some organizations may wish to keep their keylists private. While 400 this may be achievable by serving keylists at URIs only accessible 401 from specific subnets, keylists are designed to be public documents. 402 As such, clients may leak the contents of keylists to keyservers -- 403 this specification ensures to the best of its ability the integrity 404 of keylists, but not the privacy of keylists. 406 8. IANA Considerations 408 This document has no actions for IANA. 410 9. References 412 9.1. Normative References 414 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 415 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 416 DOI 10.17487/RFC1928, March 1996, 417 . 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, 421 DOI 10.17487/RFC2119, March 1997, 422 . 424 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 425 DOI 10.17487/RFC2818, May 2000, 426 . 428 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 429 Resource Identifier (URI): Generic Syntax", STD 66, 430 RFC 3986, DOI 10.17487/RFC3986, January 2005, 431 . 433 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 434 Thayer, "OpenPGP Message Format", RFC 4880, 435 DOI 10.17487/RFC4880, November 2007, 436 . 438 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 439 (DANE) Bindings for OpenPGP", RFC 7929, 440 DOI 10.17487/RFC7929, August 2016, 441 . 443 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 444 Interchange Format", STD 90, RFC 8259, 445 DOI 10.17487/RFC8259, December 2017, 446 . 448 9.2. URIs 450 [1] https://github.com/firstlookmedia/keylist-rfc 452 Authors' Addresses 454 R. Miles McCain 455 First Look Media 457 Email: ietf@sendmiles.email 458 URI: https://rmrm.io 460 Micah Lee 461 The Intercept 463 Email: micah.lee@theintercept.com 464 URI: https://micahflee.com/ 465 Nat Welch 466 Google 468 Email: nat@natwelch.com 469 URI: https://natwelch.com