idnits 2.17.1 draft-josefsson-openpgp-mailnews-header-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 438. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 462. 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 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 (May 20, 2008) is 5817 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) -- 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 10 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 May 20, 2008 5 Expires: November 21, 2008 7 The "OpenPGP" mail and news header field 8 draft-josefsson-openpgp-mailnews-header-06 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 21, 2008. 35 Abstract 37 This document describes the "OpenPGP" mail and news header field. 38 The field provide information about the sender's OpenPGP key. 40 See for more information. 42 Table of Contents 44 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Background and Motivation . . . . . . . . . . . . . . . . . . 3 46 3. OpenPGP Header Field . . . . . . . . . . . . . . . . . . . . . 4 47 3.1. Primary Key ID field: id . . . . . . . . . . . . . . . . . 5 48 3.2. Key URL field: url . . . . . . . . . . . . . . . . . . . . 6 49 3.3. Protection Preference Field: preference . . . . . . . . . 6 50 4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 52 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 53 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 54 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 55 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 56 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 57 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 58 Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 11 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 60 Intellectual Property and Copyright Statements . . . . . . . . . . 12 62 1. Preface 64 This document is intended to define the "OpenPGP" message header 65 field. This field should be considered "informational" (and 66 "optional"), and be suitable for both mail [RFC2822] and netnews 67 [RFC1036] messages. This field should be used to provide information 68 about the sender's OpenPGP [RFC4880] key. This field MAY be used in 69 any message. 71 This document should be interpreted within the context of RFC 2822. 72 In the event of a discrepancy, refer to that document. 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119 [RFC2119]. 78 2. Background and Motivation 80 There are quite a few PGP and GnuPG users who add header fields with 81 information about the sender's OpenPGP key. Fields in current use 82 include "X-PGP:", "X-PGP-Key:", "X-Request-PGP:", "X-PGP-KeyID:", and 83 "X-PGP-Fingerprint:". The fields are not standardized, so they 84 cannot be reliably parsed automatically by applications, only parsed 85 by humans. 87 Since both PGP and GnuPG rely on the OpenPGP protocol, it appears 88 preferable to use the term "OpenPGP" rather than "PGP", or "GPG", in 89 the field name. The latter forms appear as underhanded attempts to 90 advocate specific applications, rather than the open standard they 91 both share. The field specified here is named "OpenPGP". 93 The OpenPGP field is not a required part of successful use of OpenPGP 94 in e-mail or other messages. It is intended as a convenience, in 95 those situations where the user experience may be enhanced by using 96 the information in the field. Consequently, the information in the 97 field should not disrupt the normal OpenPGP key retrieval and web of 98 trust mechanism. Neither the integrity nor the authenticity of the 99 information in the field should be assumed to be correct or trust- 100 worthy. 102 This document neither suggests a specific scenario of when the field 103 should be used, nor how it should be used. It is acknowledged that 104 the dominant use of the information in the field may be by humans and 105 not applications. 107 To promote good use of the field, care should be taken so that 108 applications do not trigger error messages that may annoy the user, 109 when an error condition arises during handling of the OpenPGP field. 110 It is generally recommended that an implementation ignore the 111 presence of an OpenPGP field if it would cause an error condition. 112 Since the field is optional, this approach should not be difficult to 113 implement. The philosophy here is to enable an enhanced user 114 experience. Error messages rarely contribute to that goal. 116 3. OpenPGP Header Field 118 The OpenPGP header field is intended to present characteristics of 119 the sender's OpenPGP key. The field typically contains the Key ID 120 and the URL where the key can be retrieved. 122 Because the mail header is typically not integrity protected, the 123 information conveyed in the OpenPGP header field MUST NOT be trusted 124 without additional verification. Some of the information given in 125 this field may also be given in the OpenPGP key itself. When these 126 two sources conflict, users SHOULD favor the information from the 127 OpenPGP key, as that information can be cryptographically protected. 129 The field is of a "structured" type (see section 2.2.2 of RFC 2822). 130 In general, the structure consist of one or more parameters, each 131 consisting of one attribute and one value. The terminology and 132 format of the field was inspired by MIME [RFC2045]. The various 133 provisions of RFC 2045 apply. In particular, the value part of 134 parameters may be quoted; whitespace, folding and comments may occur 135 in the middle of parameters; except as noted below. The provisions 136 of MIME Parameter Extensions [RFC2231] also apply; in particular, 137 that document deals with handling parameters of excessive length. 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 [RFC2822] 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:" SP o-params CRLF 155 ; CFWS is defined in RFC 2822. 156 ; SP and CRLF are 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 = absoluteURI / quoted-url 171 ; absoluteURI is defined in RFC 3986. 172 ; If the URL contains the character ";", 173 ; the quoted-url form MUST be used. 175 quoted-url = DQUOTE absoluteURI DQUOTE 176 ; DQUOTE is defined in RFC 5234. 178 preference = "sign" / "encrypt" / "signencrypt" / "unprotected" 179 ; Matching of values is case-insensitive. 181 3.1. Primary Key ID field: id 183 The "id" parameter, if present, MUST hold the Key ID or key 184 fingerprint for the primary key. The value uses the hex [RFC4648] 185 notation. The parameter value is case-insensitive. 187 The length of the field determines whether it denotes a Key ID (8 hex 188 symbols), a long Key ID (16 hex symbols), a v3 key fingerprint (32 189 hex symbols), or a v4 key fingerprint (40 hex symbols). 191 Note that each of the following examples includes a comment, which is 192 optional. 194 id=12345678 (short key ID) 195 id=1234567890ABCDEF (long key ID) 196 id=1234567890abcdef0123456789ABCDEF01234567 (v4 fingerprint) 197 id=1234567890ABCDEF0123456789ABCDEF (v3 fingerprint, deprecated) 199 3.2. Key URL field: url 201 The "url" parameter, if present, MUST specify a URL where the public 202 key can be found. It is RECOMMENDED to use a common URL family, such 203 as HTTP [RFC2616] or FTP [RFC0959]. The URL MUST be fully qualified, 204 MUST explicitly specify a protocol and SHOULD be accessible on the 205 public Internet. 207 The content of where the URL points SHOULD be either an ASCII armored 208 or binary OpenPGP packet containing the key. A valid reason for 209 storing something else may be if the key has been revoked. 211 For example: 213 url=http://example.org/pgp.txt 214 url="http://example.org/funny;name.txt" 216 If the URL contains the character ';' the entire URL MUST be quoted, 217 as illustrated in the example. 219 3.3. Protection Preference Field: preference 221 The "preference" parameter, if present, specify the quality of 222 protection preferred by the sender. The parameter value is case- 223 insensitive. 225 The available values are as follows. A "unprotected" token means 226 that the sender prefers not to receive OpenPGP protected e-mails. A 227 "sign" token means that the sender prefers to receive digitally 228 signed e-mails. A "encrypt" token means that the sender prefers to 229 receive encrypted e-mails. A "signencrypt" token means that the 230 sender prefers to receive encrypted and signed e-mails. 232 Note that there is no normative requirement on the receiver to follow 233 the stated preference. 235 For example: 237 preference=sign 238 preference=unprotected 239 preference=ENCRYPT 241 4. Comments 243 As discussed in section 3.2.3 of RFC 2822, comments may appear in 244 header field bodies. Comments are not intended to be interpreted by 245 any application, but to provide additional information for humans. 247 The following are examples of OpenPGP fields with comments: 249 id=B565716F (key stored on non-networked laptop) 250 id=12345678 (1024 bit RSA Key for Encrypt or Sign) 251 id=ABCD0123 (created Sun Jan 2 02:25:15 CET 2005) 253 5. Examples 255 These are valid examples of how the field may be used. This list is 256 not meant to be exhaustive, but to reflect expected typical usages. 258 OpenPGP: id=12345678 259 OpenPGP: url=http://example.com/key.txt 260 OpenPGP: preference=unprotected 261 OpenPGP: url=http://example.com/key.txt; id=12345678 262 OpenPGP: id=12345678; url=http://example.com/key.txt; 263 preference=signencrypt 264 OpenPGP: url=http://example.com/key.txt (down 2-3pm UTC); 265 id=12345678 (this key is only used at the office); 266 preference=sign (unsigned emails are filtered away) 267 OpenPGP: id=12345678; url="http://example.com/openpgp;key.txt" 269 6. Acknowledgements 271 The content of this document builds on discussions with (in 272 alphabetical order) Christian Biere, Patrick Brunschwig, Jon Callas, 273 Dave Evans, Alfred Hoenes, Peter J. Holzer, Ingo Klocker, Werner 274 Koch, Jochen Kupper, William Leibzon, Charles Lindsey, Aleksandar 275 Milivojevic, Xavier Maillard, Greg Sabino Mullane, Tim Polk, Thomas 276 Roessler, Moritz Schulte, Olav Seyfarth, David Shaw, Thomas Sjogren, 277 Paul Walker, and Steve Youngs. No doubt the list is incomplete. We 278 apologize to anyone we left out. 280 7. Security Considerations 282 The OpenPGP header field is intended to be a convenience in locating 283 public keys; it is neither secure nor intended to be. Since the 284 message header is easy to spoof, information contained in the header 285 should not be trusted. The information must be verified. 287 Applications that interpret the field MUST NOT assume that the 288 content is correct, and MUST NOT present the data to the user in any 289 way that would cause the user to assume that it is correct. 290 Applications that interpret the data within the field SHOULD alert 291 the user that this information is not a substitute for personally 292 verifying keys and being a part of the web of trust. 294 If an application receives a signed message and uses the information 295 in the field to automatically retrieve a key, the application MAY 296 ignore the retrieved key if it is not the same key used to sign the 297 message. This SHOULD be done before the newly retrieved key is 298 imported into the user's keyring. 300 The use of HTTPS [RFC2818], DNSSEC [RFC4033], SMTP STARTTLS 301 [RFC3207], IMAP/POP3 STARTTLS [RFC2595] and other secure protocols, 302 may enhance the security of information conveyed through this field, 303 but does not guarantee any level of security or authenticity. 304 Developers and users must remain aware of this. 306 Version 3 OpenPGP keys can be created with a chosen key id (aka "the 307 0xDEADBEEF attack"). Verifying the Key ID of a retrieved key against 308 the one provided in the field is thus not sufficient to protect 309 against a man-in-the-middle attack. Instead, the web-of-trust 310 mechanism should be used. 312 If an attacker wants to check the validity of email addresses, he 313 might email arbitrary addresses with a unique OpenPGP header field 314 URL (presumably an URL under the attacker's control). The attacker 315 can verify the liveness of each email address by checking if the URL 316 for each particular recipient has been retrieved. To protect against 317 this, implementations MUST inform the user of that potential privacy 318 issue when retrieving keys from an URL provided by the field of an 319 inbound email message: either when the feature is enabled or to be 320 used for the first time or every time the MUA detects an unknown key. 322 Given the flexibility of the syntax of the field, slightly varying 323 the content between messages can be used as a covert channel. This 324 is already possible using other header fields in email, and thus the 325 OpenPGP field does not introduce a new vulnerability here. 327 8. IANA Considerations 329 The IANA is asked to register the OpenPGP header field, using the 330 template as follows, in accordance with RFC 3864 [RFC3864]. 332 Header field name: OpenPGP 334 Applicable protocol: mail, netnews 336 Status: informational 338 Author/Change controller: IETF 339 Specification document(s): This document. 341 Related information: None 343 9. References 345 9.1. Normative References 347 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 348 Extensions (MIME) Part One: Format of Internet Message 349 Bodies", RFC 2045, November 1996. 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, March 1997. 354 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 355 Word Extensions: 356 Character Sets, Languages, and Continuations", RFC 2231, 357 November 1997. 359 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 360 April 2001. 362 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 363 Resource Identifier (URI): Generic Syntax", STD 66, 364 RFC 3986, January 2005. 366 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 367 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 369 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 370 Specifications: ABNF", STD 68, RFC 5234, January 2008. 372 9.2. Informative References 374 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 375 STD 9, RFC 959, October 1985. 377 [RFC1036] Horton, M. and R. Adams, "Standard for interchange of 378 USENET messages", RFC 1036, December 1987. 380 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 381 RFC 2595, June 1999. 383 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 384 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 385 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 387 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 389 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 390 Transport Layer Security", RFC 3207, February 2002. 392 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 393 Procedures for Message Header Fields", BCP 90, RFC 3864, 394 September 2004. 396 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 397 Rose, "DNS Security Introduction and Requirements", 398 RFC 4033, March 2005. 400 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 401 Encodings", RFC 4648, October 2006. 403 Appendix A. Copying conditions 405 Regarding this entire document or any portion of it, the authors 406 makes no guarantees and is not responsible for any damage resulting 407 from its use. The authors grants irrevocable permission to anyone to 408 use, modify, and distribute it in any way that does not diminish the 409 rights of anyone else to use, modify, and distribute it, provided 410 that redistributed derivative works do not contain misleading author 411 or version information. Derivative works need not be licensed under 412 similar terms. 414 Authors' Addresses 416 Atom Smasher 418 Email: atom@smasher.org (762A3B98A3C396C9C6B7582AB88D52E4D9F57808) 420 Simon Josefsson 422 Email: simon@josefsson.org (0424D4EE81A0E3D119C6F835EDA21E94B565716F) 424 Full Copyright Statement 426 Copyright (C) The IETF Trust (2008). 428 This document is subject to the rights, licenses and restrictions 429 contained in BCP 78, and except as set forth therein, the authors 430 retain all their rights. 432 This document and the information contained herein are provided on an 433 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 434 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 435 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 436 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 437 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 438 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 440 Intellectual Property 442 The IETF takes no position regarding the validity or scope of any 443 Intellectual Property Rights or other rights that might be claimed to 444 pertain to the implementation or use of the technology described in 445 this document or the extent to which any license under such rights 446 might or might not be available; nor does it represent that it has 447 made any independent effort to identify any such rights. Information 448 on the procedures with respect to rights in RFC documents can be 449 found in BCP 78 and BCP 79. 451 Copies of IPR disclosures made to the IETF Secretariat and any 452 assurances of licenses to be made available, or the result of an 453 attempt made to obtain a general license or permission for the use of 454 such proprietary rights by implementers or users of this 455 specification can be obtained from the IETF on-line IPR repository at 456 http://www.ietf.org/ipr. 458 The IETF invites any interested party to bring to its attention any 459 copyrights, patents or patent applications, or other proprietary 460 rights that may cover technology that may be required to implement 461 this standard. Please address the information to the IETF at 462 ietf-ipr@ietf.org.