idnits 2.17.1 draft-mccain-keylist-04.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 (March 6, 2019) is 1870 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 426 ** 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: September 7, 2019 TI 6 N. Welch 7 Google 8 March 6, 2019 10 Distributing OpenPGP Key Fingerprints with Signed Keylist Subscriptions 11 draft-mccain-keylist-04 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, even in cases where the keys correspond 18 to multiple (potentially uncontrolled) domains. Ensuring that all 19 members or followers of an organization have their colleagues' most 20 recent PGP public keys is critical to maintaining operational 21 security. Without the most recent keys' fingerprints and a source of 22 trust for those keys (as this document specifies), users must 23 manually update and sign each others' keys -- a system that is 24 untenable in larger organizations. This document proposes a 25 experimental format for the keylist file as well as requirements for 26 clients who wish to implement this experimental keylist subscription 27 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 September 7, 2019. 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 . . . . . . . . . 5 71 3. Data Element Formats . . . . . . . . . . . . . . . . . . . . 6 72 3.1. Keylist . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.2. Signature . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.3. Well-Known URL . . . . . . . . . . . . . . . . . . . . . 7 75 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 76 5. Security Benefits . . . . . . . . . . . . . . . . . . . . . . 8 77 6. Relation to Other Technologies . . . . . . . . . . . . . . . 8 78 6.1. Web Key Directories . . . . . . . . . . . . . . . . . . . 8 79 6.2. OPENPGPKEY DNS Records . . . . . . . . . . . . . . . . . 8 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 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] . 114 The term "keylist" is defined as a list of OpenPGP public key 115 fingerprints and accessible via a URI. The exact format of this data 116 is specified in Section 3. Keylists SHOULD be treated as public 117 documents; although a system administrator MAY choose, for example, 118 to restrict access to a keylist to a specific subnet. 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. 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. 200 2. Obtain a current copy of the keylist's signature data from its 201 URI, which is included in the keylist data format specified in 202 Section 3. 204 3. Using the keylist and the keylist's signature, cryptographically 205 verify that the keylist was signed using the authority key. If 206 the signature does not verify, the client MUST abort the update 207 of this keylist and SHOULD alert the user. The client SHOULD NOT 208 abort the update of other keylists to which it is subscribed, 209 unless they too fail signature verification. 211 4. Validate the format of the keylist according to Section 3 . If 212 the keylist is in an invalid format, the client MUST abort the 213 update this keylist and SHOULD alert the user. 215 5. For each fingerprint listed in the keyfile, if a copy of the 216 associated public key is not present in the client's local 217 keystore, retrieve it from the keyserver specified by the keylist 218 (see Section 3) or, if the keylist specifies no keyserver, from 219 any keyserver. If the key is already present and not revoked, 220 refresh it from a keyserver. If it is present and revoked, do 221 nothing. 223 2.3. Cryptographic Verification of Keylists 225 To ensure authenticity of a keylist during an update, the client MUST 226 verify that the keylist's data matches its cryptographic signature, 227 and that the public key used to verify the signature matches the 228 authority key fingerprint given by the user. 230 For enhanced security, it is RECOMMENDED that keylist operators sign 231 each public key listed in their keylist with the authority private 232 key. This way, an organization can have an internal trust 233 relationship without requiring members of the organization to certify 234 each other's public keys. 236 3. Data Element Formats 238 The following are format specifications for the keylist file and its 239 signature file. 241 3.1. Keylist 243 The keylist MUST be a valid JavaScript Object Notation (JSON) Data 244 Interchange Format [RFC8259] object with specific keys and values, as 245 defined below. Note that unless otherwise specified, 'key' in this 246 section refers to JSON keys -- not OpenPGP keys. 248 To encode metadata, the keylist MUST have a "metadata" root key with 249 an object as the value ("metadata object"). The metadata object MUST 250 contain a "signature_uri" key whose value is the URI string of the 251 keylist's signature file. All metadata keys apart from 252 "signature_uri" are OPTIONAL. 254 The metadata object MAY contain a "keyserver" key with the value of 255 the URI string of the keyserver from which the OpenPGP keys in the 256 keylist should be retrieved. 258 The metadata object MAY contain a "comment" key with the value of any 259 string. The metadata object MAY also contain other arbitrary key- 260 value pairs. 262 The keylist MUST have a "keys" key with an array as the value. This 263 array contains a list of OpenPGP key fingerprints and metadata about 264 them. Each item in the array MUST be an object. Each of these 265 objects MUST have a "fingerprint" key with the value of a string that 266 contains the full 40-character hexadecimal public key fingerprint, as 267 defined in OpenPGP Message Format [RFC4880] . Any number of space 268 characters (' ', U+0020) MAY be included at any location in the 269 fingerprint string. These objects MAY contain "name", "email", and 270 "comment" key-value pairs, as well as any other key-value pairs 271 relevant. 273 The following is an example of a valid keylist. 275 { 276 "metadata": { 277 "signature_uri": "https://www.example.com/keylist.json.asc", 278 "comment": "This is an example of a keylist file" 279 }, 280 "keys": [ 281 { 282 "fingerprint": "927F419D7EC82C2F149C1BD1403C2657CD994F73", 283 "name": "Micah Lee", 284 "email": "micah.lee@theintercept.com", 285 "comment": "Each key can have a comment" 286 }, 287 { 288 "fingerprint": "1326CB162C6921BF085F8459F3C78280DDBF52A1", 289 "name": "R. Miles McCain", 290 "email": "0@rmrm.io" 291 }, 292 { 293 "fingerprint": "E0BE0804CF04A65C1FC64CC4CAD802E066046C02", 294 "name": "Nat Welch", 295 "email": "nat.welch@firstlook.org" 296 } 297 ] 298 } 300 3.2. Signature 302 The signature file MUST be an ASCII-armored 'detached signature' of 303 the keylist file, as defined in OpenPGP Message Format [RFC4880] . 305 3.3. Well-Known URL 307 Keylists SHOULD NOT be well-known resources [RFC4880]. To subscribe 308 to a keylist, the client must be aware not only of the keylist's 309 location, but also of the fingerprint of the authority public key 310 used to sign the keylist. Furthermore, because keylists can 311 reference public keys from several different domains, the host of the 312 well-known location for a keylist may not always be clear. 314 4. Implementation Status 316 GPG Sync, an open source program created by one of the authors, 317 implements this experimental standard. GPG Sync is used by First 318 Look Media and the Freedom of the Press Foundation to keep OpenPGP 319 keys in sync across their organizations, as well as to publish their 320 employee's OpenPGP keys to the world. These organizations 321 collectively employ more than 200 people and have used the system 322 described in this document successfully for multiple years. 324 GPG Sync's existing code can be found at 325 327 First Look Media's keylist file can be found at 328 330 5. Security Benefits 332 The keylist subscription functionality defined in this document 333 provides a number of security benefits, including: 335 o The ability for new keys to be quickly distributed across an 336 organization. 338 o Removing the complexity of key distribution from end users, 339 allowing them to focus on the content of their communications 340 rather than on key management. 342 o The ability for an organization to prevent the spread of falsely 343 attributed keys by centralizing the public key discovery process 344 within their organization without centralized public key hosting. 346 6. Relation to Other Technologies 348 6.1. Web Key Directories 350 Unlike Web Key Directories, keylists are not domain specific. A 351 keylist might contain public key fingerprints for email addresses 352 across several different domains. Moreover, keylists only provide 353 references to public keys by way of fingerprints; Web Key Directories 354 provide the public keys themselves. 356 6.2. OPENPGPKEY DNS Records 358 A keylist MAY reference public keys corresponding to email addresses 359 across several different domains. Because managing OPENPGPKEY DNS 360 Records [RFC7929] for a particular domain requires control of that 361 domain, the OPENPGPKEY DNS Record system is not suitable for cases in 362 which keys are strewn about several different domains, including ones 363 outside of the control of an organization's system adminitrators. 365 7. Security Considerations 367 There is a situation in which keylist subscriptions could pose a 368 potential security threat. If both the authority key and the keylist 369 distribution system were to be compromised, it would be possible for 370 an attacker to distribute any key of their choosing to the 371 subscribers of the keylist. The potential consequences of this 372 attack are limited, however, because the attacker cannot remove or 373 modify the keys already present on subscribers' systems. 375 Some organizations may wish to keep their keylists private. While 376 this may be achievable by serving keylists at URIs only accessible 377 from specific subnets, keylists are designed to be public documents. 378 As such, clients may leak the contents of keylists to keyservers -- 379 this specification ensures to the best of its ability the integrity 380 of keylists, but not the privacy of keylists. 382 8. IANA Considerations 384 This document has no actions for IANA. 386 9. References 388 9.1. Normative References 390 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 391 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 392 DOI 10.17487/RFC1928, March 1996, 393 . 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, 397 DOI 10.17487/RFC2119, March 1997, 398 . 400 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 401 DOI 10.17487/RFC2818, May 2000, 402 . 404 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 405 Resource Identifier (URI): Generic Syntax", STD 66, 406 RFC 3986, DOI 10.17487/RFC3986, January 2005, 407 . 409 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 410 Thayer, "OpenPGP Message Format", RFC 4880, 411 DOI 10.17487/RFC4880, November 2007, 412 . 414 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 415 (DANE) Bindings for OpenPGP", RFC 7929, 416 DOI 10.17487/RFC7929, August 2016, 417 . 419 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 420 Interchange Format", STD 90, RFC 8259, 421 DOI 10.17487/RFC8259, December 2017, 422 . 424 9.2. URIs 426 [1] https://github.com/firstlookmedia/keylist-rfc 428 Authors' Addresses 430 R. Miles McCain 431 First Look Media 433 Email: ietf@sendmiles.email 434 URI: https://rmrm.io 436 Micah Lee 437 The Intercept 439 Email: micah.lee@theintercept.com 440 URI: https://micahflee.com/ 442 Nat Welch 443 Google 445 Email: nat@natwelch.com 446 URI: https://natwelch.com