idnits 2.17.1 draft-josefsson-openpgp-mailnews-header-07.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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 28, 2014) is 3529 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1036 (Obsoleted by RFC 5536, RFC 5537) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Smasher 3 Internet-Draft S. Josefsson 4 Intended status: Informational August 28, 2014 5 Expires: March 1, 2015 7 The "OpenPGP" mail and news header field 8 draft-josefsson-openpgp-mailnews-header-07 10 Abstract 12 This document describes the "OpenPGP" mail and news header field. 13 The field provide information about the sender's OpenPGP key. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on March 1, 2015. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Background and Motivation . . . . . . . . . . . . . . . . . . 3 51 3. OpenPGP Header Field . . . . . . . . . . . . . . . . . . . . . 4 52 3.1. Primary Key ID field: id . . . . . . . . . . . . . . . . . 5 53 3.2. Key URL field: url . . . . . . . . . . . . . . . . . . . . 6 54 3.3. Protection Preference Field: preference . . . . . . . . . 6 55 4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 62 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 63 Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 11 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 66 1. Preface 68 This document define the "OpenPGP" message header field. This field 69 is suitable for both mail [RFC5322] and netnews [RFC1036] messages, 70 and is used to provide information about the sender's OpenPGP 71 [RFC4880] key. 73 This document should be interpreted within the context of [RFC5322]. 74 In the event of a discrepancy, refer to that document. 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [RFC2119]. 80 2. Background and Motivation 82 There are quite a few PGP and GnuPG users who add header fields with 83 information about the sender's OpenPGP key. Fields in current use 84 include "X-PGP:", "X-PGP-Key:", "X-Request-PGP:", "X-PGP-KeyID:", and 85 "X-PGP-Fingerprint:". The fields are not standardized, so they 86 cannot be reliably parsed automatically by applications, only parsed 87 by humans. 89 Since both PGP and GnuPG rely on the OpenPGP protocol, it appears 90 preferable to use the term "OpenPGP" rather than "PGP", or "GPG", in 91 the field name. The latter forms appear as underhanded attempts to 92 advocate specific applications, rather than the open standard they 93 both share. The field specified here is named "OpenPGP". 95 The OpenPGP field is not a required part of successful use of OpenPGP 96 in e-mail or other messages. It is intended as a convenience, in 97 those situations where the user experience may be enhanced by using 98 the information in the field. Consequently, the information in the 99 field should not disrupt the normal OpenPGP key retrieval and web of 100 trust mechanism. Neither the integrity nor the authenticity of the 101 information in the field should be assumed to be correct or trust- 102 worthy. 104 This document neither suggests a specific scenario of when the field 105 should be used, nor how it should be used. It is acknowledged that 106 the dominant use of the information in the field may be by humans and 107 not applications. 109 To promote good use of the field, care should be taken so that 110 applications do not trigger error messages that may annoy the user, 111 when an error condition arises during handling of the OpenPGP field. 112 It is generally recommended that an implementation ignore the 113 presence of an OpenPGP field if it would cause an error condition. 114 Since the field is optional, this approach should not be difficult to 115 implement. The philosophy here is to enable an enhanced user 116 experience. Error messages rarely contribute to that goal. 118 3. OpenPGP Header Field 120 The OpenPGP header field is intended to present characteristics of 121 the sender's OpenPGP key. The field typically contains the Key ID 122 and the URL where the key can be retrieved. 124 Because the mail header is typically not integrity protected, the 125 information conveyed in the OpenPGP header field MUST NOT be trusted 126 without additional verification. Some of the information given in 127 this field may also be given in the OpenPGP key itself. When these 128 two sources conflict, users SHOULD favor the information from the 129 OpenPGP key, as that information can be cryptographically protected. 131 The field is of a "structured" type (see section 2.2.2 of RFC 5322). 132 In general, the structure consist of one or more parameters, each 133 consisting of one attribute and one value. The terminology and 134 format of the field was inspired by MIME [RFC2045]. The various 135 provisions of RFC 2045 apply. In particular, the value part of 136 parameters may be quoted; whitespace, folding and comments may occur 137 in the middle of parameters; except as noted below. 139 The OpenPGP header field is defined below in the Augmented BNF 140 [RFC5234] notation. By itself, however, this grammar is incomplete. 141 It refers by name to syntax rules that are defined in [RFC5322] and 142 [RFC3986]. Rather than reproduce those definitions here, and risk 143 unintentional differences between the two, this document refers the 144 reader to the other documents for the definition of non-terminals. 146 Implementations MUST understand the "id", "url", and "preference" 147 attributes. Parameter with unrecognized attributes MUST be ignored. 148 The grammar permits unknown parameters to allow for future 149 extensions. Each parameter attribute (e.g., "url") MUST NOT occur 150 more than once in any single instance of the OpenPGP field. The 151 OpenPGP field itself MAY occur more than once in a single email (for 152 example if the sender has multiple keys). 154 openpgp = "OpenPGP:" o-params CRLF 155 ; CFWS is defined in RFC 5322. 156 ; CRLF is defined in RFC 5234. 158 o-params = (o-parameter *(";" o-parameter)) 160 o-parameter = *CFWS "id" "=" id *CFWS 161 / *CFWS "url" "=" url *CFWS 162 / *CFWS "preference" "=" preference *CFWS 163 / *CFWS parameter *CFWS ; normally unused, for extensions 164 ; parameter is defined in RFC 2045. 166 id = 1*(8HEXDIG) 167 ; HEXDIG is defined in RFC 5234. 168 ; Matching of value is case-insensitive. 170 url = folded-uri / quoted-url 171 ; If the URL contains the character ";", 172 ; the quoted-url form MUST be used. 174 quoted-url = DQUOTE folded-uri DQUOTE 175 ; DQUOTE is defined in RFC 5234. 177 folded-uri = 178 ; absoluteURI is defined in RFC 3986. 179 ; FWS is defined in RFC 5234. 181 preference = "sign" / "encrypt" / "signencrypt" / "unprotected" 182 ; Matching of values is case-insensitive. 184 The folded-URI MAY contain folding whitespace (FWS, [RFC5322]), which 185 is ignored. To convert a folded-URI to a absolute-URI, first apply 186 standard [RFC5322] unfolding rules (replacing FWS with a single SP), 187 and then delete any remaining un-encoded SP characters. Folding may 188 be used to shorten long lines. 190 3.1. Primary Key ID field: id 192 The "id" parameter, if present, MUST hold the Key ID or key 193 fingerprint for the primary key. The value uses the hex [RFC4648] 194 notation. The parameter value is case-insensitive. 196 The length of the field determines whether it denotes a Key ID (8 hex 197 symbols), a long Key ID (16 hex symbols), a v3 key fingerprint (32 198 hex symbols), or a v4 key fingerprint (40 hex symbols). 200 Note that each of the following examples includes a comment, which is 201 optional. 203 id=12345678 (short key ID) 204 id=1234567890ABCDEF (long key ID) 205 id=1234567890abcdef0123456789ABCDEF01234567 (v4 fingerprint) 206 id=1234567890ABCDEF0123456789ABCDEF (v3 fingerprint, deprecated) 208 3.2. Key URL field: url 210 The "url" parameter, if present, MUST specify a URL where the public 211 key can be found. It is RECOMMENDED to use a common URL family, such 212 as HTTP [RFC2616] or FTP [RFC0959]. The URL MUST be fully qualified, 213 MUST explicitly specify a protocol and SHOULD be accessible on the 214 public Internet. 216 The content of where the URL points SHOULD be either an ASCII armored 217 or binary OpenPGP packet containing the key. A valid reason for 218 storing something else may be if the key has been revoked. 220 For example: 222 url=http://example.org/pgp.txt 223 url="http://example.org/funny;name.txt" 225 If the URL contains the character ';' the entire URL MUST be quoted, 226 as illustrated in the example. 228 3.3. Protection Preference Field: preference 230 The "preference" parameter, if present, specify the quality of 231 protection preferred by the sender. The parameter value is case- 232 insensitive. 234 The available values are as follows. The "unprotected" token means 235 that the sender prefers not to receive OpenPGP protected e-mails. 236 The "sign" token means that the sender prefers to receive digitally 237 signed e-mails. The "encrypt" token means that the sender prefers to 238 receive encrypted e-mails. A "signencrypt" token means that the 239 sender prefers to receive encrypted and signed e-mails. 241 Note that there is no normative requirement on the receiver to follow 242 the stated preference. 244 For example: 246 preference=sign 247 preference=unprotected 248 preference=ENCRYPT 250 4. Comments 252 As discussed in section 3.2.2 of RFC 5322, comments may appear in 253 header field bodies. Comments are not intended to be interpreted by 254 any application, but to provide additional information for humans. 256 The following are examples of OpenPGP fields with comments: 258 id=B565716F (key stored on non-networked laptop) 259 id=12345678 (1024 bit RSA Key for Encrypt or Sign) 260 id=ABCD0123 (created Sun Jan 2 02:25:15 CET 2005) 262 5. Examples 264 These are valid examples of how the field may be used. This list is 265 not meant to be exhaustive, but to reflect expected typical usages. 267 OpenPGP: id=12345678 268 OpenPGP: url=http://example.com/key.txt 269 OpenPGP: preference=unprotected 270 OpenPGP: url=http://example.com/key.txt; id=12345678 271 OpenPGP: id=12345678; url=http://example.com/key.txt; 272 preference=signencrypt 273 OpenPGP: url=http://example.com/key.txt (down 2-3pm UTC); 274 id=12345678 (this key is only used at the office); 275 preference=sign (unsigned emails are filtered away) 276 OpenPGP: id=12345678; url="http://example.com/openpgp;key.txt" 278 6. Acknowledgements 280 The content of this document builds on discussions with (in 281 alphabetical order) Christian Biere, Patrick Brunschwig, Jon Callas, 282 Dave Evans, Alfred Hoenes, Peter J. Holzer, Ingo Klocker, Werner 283 Koch, Jochen Kupper, William Leibzon, Charles Lindsey, Aleksandar 284 Milivojevic, Xavier Maillard, Greg Sabino Mullane, Tim Polk, Thomas 285 Roessler, Moritz Schulte, Olav Seyfarth, David Shaw, Thomas Sjogren, 286 Paul Walker, and Steve Youngs. No doubt the list is incomplete. We 287 apologize to anyone we left out. 289 7. Security Considerations 291 The OpenPGP header field is intended to be a convenience in locating 292 public keys; it is neither secure nor intended to be. Since the 293 message header is easy to spoof, information contained in the header 294 should not be trusted. The information must be verified. 296 Applications that interpret the field MUST NOT assume that the 297 content is correct, and MUST NOT present the data to the user in any 298 way that would cause the user to assume that it is correct. 299 Applications that interpret the data within the field SHOULD alert 300 the user that this information is not a substitute for personally 301 verifying keys and being a part of the web of trust. 303 If an application receives a signed message and uses the information 304 in the field to automatically retrieve a key, the application MAY 305 ignore the retrieved key if it is not the same key used to sign the 306 message. This SHOULD be done before the newly retrieved key is 307 imported into the user's keyring. 309 The use of HTTPS [RFC2818], DNSSEC [RFC4033], SMTP STARTTLS 310 [RFC3207], IMAP/POP3 STARTTLS [RFC2595] and other secure protocols, 311 may enhance the security of information conveyed through this field, 312 but does not guarantee any level of security or authenticity. 313 Developers and users must remain aware of this. 315 Version 3 OpenPGP keys can be created with a chosen key id (aka "the 316 0xDEADBEEF attack"). Verifying the Key ID of a retrieved key against 317 the one provided in the field is thus not sufficient to protect 318 against a man-in-the-middle attack. Instead, the web-of-trust 319 mechanism should be used. 321 If an attacker wants to check the validity of email addresses, he 322 might email arbitrary addresses with a unique OpenPGP header field 323 URL (presumably an URL under the attacker's control). The attacker 324 can verify the liveness of each email address by checking if the URL 325 for each particular recipient has been retrieved. To protect against 326 this, implementations MUST inform the user of that potential privacy 327 issue when retrieving keys from an URL provided by the field of an 328 inbound email message: either when the feature is enabled or to be 329 used for the first time or every time the MUA detects an unknown key. 331 Given the flexibility of the syntax of the field, slightly varying 332 the content between messages can be used as a covert channel. This 333 is already possible using other header fields in email, and thus the 334 OpenPGP field does not introduce a new vulnerability here. 336 8. IANA Considerations 338 The IANA is asked to register the OpenPGP header field, using the 339 template as follows, in accordance with RFC 3864 [RFC3864]. 341 Header field name: OpenPGP 342 Applicable protocol: mail, netnews 344 Status: informational 346 Author/Change controller: IETF 348 Specification document(s): This document. 350 Related information: None 352 9. References 354 9.1. Normative References 356 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 357 Extensions (MIME) Part One: Format of Internet Message 358 Bodies", RFC 2045, November 1996. 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, March 1997. 363 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 364 Resource Identifier (URI): Generic Syntax", STD 66, 365 RFC 3986, January 2005. 367 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 368 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 370 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 371 Specifications: ABNF", STD 68, RFC 5234, January 2008. 373 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 374 October 2008. 376 9.2. Informative References 378 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 379 STD 9, RFC 959, October 1985. 381 [RFC1036] Horton, M. and R. Adams, "Standard for interchange of 382 USENET messages", RFC 1036, December 1987. 384 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 385 RFC 2595, June 1999. 387 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 388 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 389 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 391 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 393 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 394 Transport Layer Security", RFC 3207, February 2002. 396 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 397 Procedures for Message Header Fields", BCP 90, RFC 3864, 398 September 2004. 400 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 401 Rose, "DNS Security Introduction and Requirements", 402 RFC 4033, March 2005. 404 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 405 Encodings", RFC 4648, October 2006. 407 Appendix A. Copying conditions 409 Regarding this entire document or any portion of it, the authors 410 makes no guarantees and is not responsible for any damage resulting 411 from its use. The authors grants irrevocable permission to anyone to 412 use, modify, and distribute it in any way that does not diminish the 413 rights of anyone else to use, modify, and distribute it, provided 414 that redistributed derivative works do not contain misleading author 415 or version information. Derivative works need not be licensed under 416 similar terms. 418 Authors' Addresses 420 Atom Smasher 422 Email: atom@smasher.org (762A3B98A3C396C9C6B7582AB88D52E4D9F57808) 424 Simon Josefsson 426 Email: simon@josefsson.org (9AA9BDB11BB1B99A21285A330664A76954265E8C)