idnits 2.17.1 draft-mccain-keylist-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 66 has weird spacing: '...ication of ...' -- The document date (August 6, 2018) is 2088 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: Experimental M. Lee 5 Expires: February 7, 2019 TI 6 N. Welch 7 FLM 8 August 6, 2018 10 Distributing OpenPGP Keys with Signed Keylist Subscriptions 11 draft-mccain-keylist-00 13 Abstract 15 This document specifies a system by which an OpenPGP client may 16 subscribe to an organization's keylist to keep its internal keystore 17 up-to-date. Ensuring that all members of an organization have their 18 colleagues' most recent PGP public keys is critical to maintaining 19 operational security. Without the most recent keys and a source of 20 trust for those keys (as this document specifies), users must 21 manually update and sign each others keys -- a system that is 22 untenable in larger organizations. This document proposes a standard 23 format for the keylist file as well as requirements for clients who 24 wish to implement keylist subscription functionality. 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 February 7, 2019. 43 Copyright Notice 45 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 2 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Functions and Procedures . . . . . . . . . . . . . . . . . . 3 64 2.1. Subscribing to Keylists . . . . . . . . . . . . . . . . . 3 65 2.2. Periodic Updates . . . . . . . . . . . . . . . . . . . . 4 66 2.3. Cryptographic Verification of Keylists . . . . . . . . 4 67 3. Data Element Formats . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Keylist . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.2. Signature . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. In Practice . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 5.1. Security Benefits . . . . . . . . . . . . . . . . . . . . 6 73 5.2. Security Drawbacks . . . . . . . . . . . . . . . . . . . 6 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 75 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 This document specifies a system by which clients may subscribe to 81 cryptographically signed keylists. This system allows for seamless 82 key rotation across entire organizations and enhances operational 83 security. To enable cross-client compatibility, this document 84 provides a standard format for the keylist, its cryptographic 85 verification, and the method by which it is retreived by the client. 86 The user interface by which a client provides this functionality to 87 the user is out of scope, as is the process by which the client 88 retrieves public keys. Other non-security-related implementation 89 details are also out of scope. 91 1.1. Requirements Notation 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119] . 97 1.2. Terminology 99 This document uses the terms "OpenPGP", "public key", "private key", 100 "signature", and "fingerprint" as defined by OpenPGP Message Format 101 [RFC4880] . 103 The term "keylist" is defined as a list of OpenPGP public keys 104 identified by their fingerprints and accessible via a URI. The exact 105 format of this data is specified in Section 3 . 107 An "authority key" is defined as the OpenPGP secret key used to sign 108 a particular keylist. Every keylist has a corresponding authority 109 key, and every authority key has at least one corresponding keylist. 110 A single authority key SHOULD NOT be used to sign multiple keylists. 112 To be "subscribed" to a keylist means that a program will retreive 113 that keylist on a regular interval. After retrieval, that program 114 will perform an update to an internal OpenPGP keystore. 116 A "client" is a program that allows the user to subscribe to 117 keylists. A client may be an OpenPGP client itself or a separate 118 program that interfaces with an OpenPGP client to update its 119 keystore. 121 2. Functions and Procedures 123 As new keys are created and other keys are revoked, it is critical 124 that all members of an organization have the most recent set of keys 125 available on their computers. Keylists enable organizations to 126 publish a directory of OpenPGP keys that clients can use to keep 127 their internal keystores up-to-date. 129 2.1. Subscribing to Keylists 131 A single client may subscribe to any number of keylists. When a 132 client first subscribes to a keylist, it SHOULD update or import 133 every key present in the keylist into its local keystore. Keylist 134 subscriptions SHOULD be persistent --that is, they should be 135 permanently stored by the client to enable future automatic updates. 137 To subscribe to a keylist, the client must be aware of the keylist 138 URI (defined in [RFC3986] ), the keylist's signature URI, and the 139 fingerprint of the authority key used to sign the keylist. The 140 protocol used to retrieve thbe keylist and its signature SHOULD be 141 HTTPS (see [RFC2818] ), however other implementation are possible. A 142 client implementing keylist functionality MUST support the retrieval 143 of keylists and signatures over HTTPS. All other protocols are 144 OPTIONAL. 146 A client MUST NOT employ a trust-on-first-use model for determining 147 the fingerprint of the authority key; it must be explicitly provided 148 by the user. 150 The process by which the client stores its keylist subscriptions is 151 out of scope, as is the means by which subscription functionality is 152 exposed to the end-user. 154 2.2. Periodic Updates 156 The primary purpose of keylists is to enable periodic updates of 157 OpenPGP clients' internal keystores. We RECOMMEND that clients 158 provide a default refresh interval of less than one day, however we 159 also RECOMMEND that clients allow the user to select this interval. 160 The exact time at which updates are performed is not critical. 162 To perform an update, the client MUST perform the following steps on 163 each keylist to which it is subscribed. The steps SHOULD be 164 performed in the given order. 166 1. Obtain a current copy of the keylist from its URI. 168 2. Obtain a current copy of the keylist's signature data from its 169 URI. 171 3. Using the keylist and the keylist's signature, cryptographically 172 verify that the keylist was signed using the authority key. If 173 the signature does not verify, the client MUST abort the update 174 of this keylist and SHOULD alert the user. The client SHOULD NOT 175 abort the update of other keylists to which it is subscribed, 176 unless they too fail signature verification. 178 4. Validate the format of the keylist according to Section 3 . If 179 the keylist is in an invalid format, the client MUST abort the 180 update this keylist and SHOULD alert the user. 182 5. For each fingerprint listed in the keyfile, if a copy of the 183 associated public key is not present in the client's local 184 keystore, retrieve it from a keyserver. If it is already present 185 and not revoked, refresh it from a keyserver. If it is present 186 and revoked, ignore it. The method by which keys are retrieved 187 and updated is out of scope. 189 2.3. Cryptographic Verification of Keylists 191 To ensure authenticity of a keylist during an update, the client MUST 192 verify that the keylist's data matches its cryptographic signature, 193 and that the public key used to verify the signature matches the 194 authority key fingerprint given by the user. 196 For enhanced security, it is RECOMMENDED that keylist operators sign 197 each public key listed in their keylist with the authority private 198 key. This way, an organization can have an internal trust 199 relationship without requiring members of the organization to certify 200 each other's public keys. 202 3. Data Element Formats 204 The following are definitions of the data types we will be creating 205 to support this new feature set. 207 3.1. Keylist 209 The keylist MUST be encoded in UTF-8 [RFC3629] . Each line MUST begin 210 either with a comment, a public key fingerprint, or whitespace. A 211 comment is defined as a string of characters between a hash symbol 212 (#, U+0023) and a newline or an end of file (EOF). The keylist 213 SHOULD end with a newline. The fingerprint MUST be the full 214 40-character hexadecimal public key fingerprint, as defined in 215 OpenPGP Message Format [RFC4880] . Space characters (' ', U+0020) MAY 216 be included anywhere in the fingerprint. Lines SHOULD NOT exceed 128 217 characters in length. 219 It is RECOMMENDED that keylist maintainers describe each key using a 220 comment, for example: 222 1326 CB16 ... DDBF 52A1 # Miles' Key 224 To extract the public key fingerprints from a keylist, a client 225 SHOULD perform the following steps, in order: 227 1. Strip the keylist of all comments, as defined above, including 228 the preceding hash symbol but excluding the trailing newline. 230 2. Strip the keylist of all non-breaking whitespace. 232 Performing these steps will result in one public key fingerprint per 233 line. 235 3.2. Signature 237 The signature file MUST be an ASCII-armored 'detached signature' of 238 the keylist file, as defined in OpenPGP Message Format [RFC4880] . 240 4. In Practice 242 GPG Sync, an open source program created by one of the authors, 243 implements this experimental standard. GPG Sync is used by First 244 Look Media and the Freedom of the Press Foundation to keep OpenPGP 245 keys in sync across their organizations, as well as to publish their 246 employee's OpenPGP keys to the world. These organizations 247 collectively employ more than 200 people and have used the system 248 described in this document successfully for multiple years. 250 GPG Sync's existing code can be found at 251 253 First Look Media's keylist file can be found at 254 256 5. Security Considerations 258 5.1. Security Benefits 260 The keylist subscription functionality defined in this document 261 provide a number of security benefits, including: 263 o The ability for new keys to be quickly distributed across an 264 organization. 266 o It removes the complexity of key distribution from end users, 267 allowing them to focus on the content of their communications 268 rather than on key management. 270 o The ability for an organization to prevent the spread of falsely 271 attributed keys by centralizing the public key discovery process 272 within their organization. 274 5.2. Security Drawbacks 276 There is a situation in which keylist subscriptions could pose a 277 potential security threat. If the authority key and the keylist 278 distribution system were to both be compromised, it would be possible 279 for an attacker to distribute false keys. We believe, however, that 280 the security benefits of this system strongly outweigh the drawbacks. 282 If the client does not perform an update regularly, there is the 283 possibility that keys will be just as outdated as they would be 284 without a keylist subscription. 286 6. IANA Considerations 288 This document has no actions for IANA. 290 7. Normative References 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, 294 DOI 10.17487/RFC2119, March 1997, 295 . 297 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 298 DOI 10.17487/RFC2818, May 2000, 299 . 301 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 302 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 303 2003, . 305 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 306 Resource Identifier (URI): Generic Syntax", STD 66, 307 RFC 3986, DOI 10.17487/RFC3986, January 2005, 308 . 310 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 311 Thayer, "OpenPGP Message Format", RFC 4880, 312 DOI 10.17487/RFC4880, November 2007, 313 . 315 Authors' Addresses 317 R. Miles McCain 318 First Look Media 320 Email: ietf@sendmiles.email 321 URI: https://rmrm.io 323 Micah Lee 324 The Intercept 326 Email: micah.lee@theintercept.com 327 URI: https://micahflee.com/ 328 Nat Welch 329 First Look Media 331 Email: nat.welch@firstlook.media 332 URI: https://natwelch.com