Network Working Group A. Smasher Internet-Draft S. Josefsson Expires: July 8, 2005 January 7, 2005 The OpenPGP mail and news header draft-josefsson-openpgp-mailnews-header-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 8, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the OpenPGP mail and news header field. The field provide information about the sender's OpenPGP key. See for more information. Smasher & Josefsson Expires July 8, 2005 [Page 1] Internet-Draft The OpenPGP mail and news header January 2005 Table of Contents 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background and Motivation . . . . . . . . . . . . . . . . . . 3 3. OpenPGP Header Field . . . . . . . . . . . . . . . . . . . . . 4 3.1 Primary Key ID field: id . . . . . . . . . . . . . . . . . 5 3.2 Primary Key Algorithm field: algo . . . . . . . . . . . . 5 3.3 Primary Key Size field: size . . . . . . . . . . . . . . . 5 3.4 Key URL field: url . . . . . . . . . . . . . . . . . . . . 6 3.5 Key Creation Date field: created . . . . . . . . . . . . . 6 4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 10.2 Informative References . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 Smasher & Josefsson Expires July 8, 2005 [Page 2] Internet-Draft The OpenPGP mail and news header January 2005 1. Preface This document is intended to define the "OpenPGP" message header. This header should be considered "informational" (and "optional"), and be suitable for both mail [6] and netnews [1] messages. This header should be used to provide information about the sender's OpenPGP [5] key. This header MAY be used in any message. This document should be interpreted within the context of RFC 2822. In the event of a discrepancy, refer to that document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. 2. Background and Motivation There are quite a few PGP and GnuPG users who add headers with information about the sender's OpenPGP key. Headers in current use include "X-PGP:", "X-PGP-Key:", "X-Request-PGP:", "X-PGP-KeyID:", and "X-PGP-Fingerprint:". The headers lack standardization, which prevent them from being reliably parsed automatically by applications, rather than manually parsed by humans. Since both PGP and GnuPG rely on the OpenPGP protocol, it appear preferable to use the term "OpenPGP" rather than "PGP", or "GPG", in the header name. The latter forms appear as underhanded attempts to advocate specific applications, rather than the open standard they both share. The header specified here is named "OpenPGP". The OpenPGP header is not a required part of successful use of OpenPGP in e-mail. It is intended as a convenience, in those situations where the user experience may be enhanced by using the information in this header. Consequently, the information in this header should not disrupt the normal OpenPGP key retrieval and web of trust mechanism. Neither the integrity nor the authenticity of the information in this header should be assumed to be correct or be trust-worthy. No specific scenario when the header should be used, nor how it should be used in that scenario, are suggested by this document. It is acknowledged that the dominant use of the information in this header may be by humans and not applications. To promote good use of this header, care should be taken so that applications do not trigger error messages that may annoy the user, when an error condition arise during handling of the OpenPGP header. It is generally recommended that an implementation ignore the Smasher & Josefsson Expires July 8, 2005 [Page 3] Internet-Draft The OpenPGP mail and news header January 2005 presence of the OpenPGP header if an error condition occur. Since the header is optional, this approach should not be difficult to implement. The philosophy here is to enable an enhanced user experience. Error messages rarely contribute to that goal. 3. OpenPGP Header Field This header, if used, is intended to present characteristics of the sender's OpenPGP key, such as the primary key ID (or fingerprint), algorithm, size and URL where the key can be found. This header is of a "structured" type (see section 2.2.2 of RFC 2822). In general, the structure consist of one or more attribute and value pairs. The terminology and format of the header was inspired by MIME [8]. This header SHOULD NOT appear more than once within a message. In the Augmented BNF [3] notation, an OpenPGP header field is defined as below. By itself, however, this grammar is incomplete. It refers by name to several syntax rules that are defined by RFC 2822 and the URI syntax document [4]. Rather than reproduce those definitions here, and risk unintentional differences between the two, this document refer the reader to RFC 2822 and RFC 2396 for the definition of non-terminals. openpgp := "OpenPGP:" id-or-url / (parameter *(";" parameter)) CRLF id-or-url := id / url id := ["0x"] (4*HEXDIG / 8*HEXDIG / 32*HEXDIG / 40*HEXDIG) url := absoluteURI ; Defined in RFC 2396. algo := *DIGIT ; Value in RFC 2440 section 9.1. size := *DIGIT ; Primary key size in bits. created := *DIGIT ; Correspond to four-octet number in ; RFC 2440 V3/V4 key packet that indicate ; the time the key was created, expressed as ; an unsigned decimal integer. parameter := ("id" "=" id) / ("url" "=" url) / ("algo" "=" algo) / ("size" "=" size) / ("created" "=" created) Smasher & Josefsson Expires July 8, 2005 [Page 4] Internet-Draft The OpenPGP mail and news header January 2005 3.1 Primary Key ID field: id The "id" attribute=value pair, if present, MUST define the primary key ID. The value MAY be prefixed with "0x". The value MUST identify the key ID (in either short or long form) or the fingerprint, all using the hexadecimal [13] notation. A short key ID is a 32 bit key ID, represented as 8 characters. A long key ID is a 64 bit key ID, represented as 16 characters. A v4 fingerprint is a 160 bit key ID, represented as 40 characters. A v3 fingerprint is a 128 bit key ID, represented as 32 characters. Note that each of the following examples includes a comment, which is optional. id=12345678 (short key ID, no 0x prefix) id=0x12345678 (short key ID) id=0x1234567890ABCDEF (long key ID) id=0x1234567890ABCDEF01234567890ABCDEF0123456 (v4 fingerprint) id=0x1234567890ABCDEF01234567890ABCDE (v3 fingerprint) 3.2 Primary Key Algorithm field: algo The "algo" attribute=value pair, if present, MUST specify the algorithm of the primary key. The algorithm of the primary key MUST be presented as the value defined in section 9.1 of RFC 2440 (Public Key Algorithms). The value MUST be presented as an integer in decimal notation. Note that each of the following examples includes a comment, which is optional. algo=1 (RSA) algo=17 (DSA) 3.3 Primary Key Size field: size The "size" attribute=value pair, if present, MUST specify the size of the primary key. The size of the primary key MUST be presented as the number of bits in the key's modulus. The value MUST be presented as an integer in decimal notation. Note that one of the following examples includes a comment, which is Smasher & Josefsson Expires July 8, 2005 [Page 5] Internet-Draft The OpenPGP mail and news header January 2005 optional. size=1024 size=2048 (bits) 3.4 Key URL field: url The "url" attribute=value pair, if present, MUST specify a URL where the public key can be found. It is RECOMMENDED to use a common URL family, such as HTTP [11] or FTP [7]. The URL MUST be fully qualified, MUST explicitly specify a protocol and SHOULD be accessible on the public Internet. For example: url=http://example.org/pgp.txt 3.5 Key Creation Date field: created This "created" attribute=value pair, if present, MUST define the creation date of the primary key. The creation date of the primary key MUST be presented as specified in section 5.5.2 of RFC2440 (Public Key Packet Formats). The value MUST be presented as a integer in decimal notation. Note that the following example includes a comment, which is optional. created=1104629466 (Sun Jan 2 01:31:06 UTC 2005) 4. Comments As discussed in section 3.2.3 of RFC 2822, comments may appear in header field bodies. Comments are not intended to be interpreted by any application, but to provide additional information for humans. The following are examples of header field bodies with comments: id=0xB565716F (key stored on non-networked laptop) id=0x12345678; algo=1 (RSA Encrypt or Sign) id=0xABCD0123; created=1104629115 (Sun Jan 2 02:25:15 CET 2005) Smasher & Josefsson Expires July 8, 2005 [Page 6] Internet-Draft The OpenPGP mail and news header January 2005 5. Examples These are valid examples of ways in which this header may be used. This list of examples is not meant to be exhaustive. OpenPGP: id=0x12345678 OpenPGP: id=0x12345678; algo=1 (RSA); size=2048 OpenPGP: url=http://example.com/key.txt OpenPGP: url=http://example.com/key.txt; id=0x12345678 (this key is only used at the office) 6. Open Issues Should the algo/size/created fields be included? They are supposedly only there for v3 keys. Should there be a "supports" field, that signal whether the sender support inline PGP or PGP/MIME? As in supports="inline, mime" or similar. Should it be in preferred priority order? 7. Acknowledgements The content of this document builds on discussions with (in alphabetical order) Christian Biere, Patrick Brunschwig, Peter J. Holzer, Ingo Klocker, Werner Koch, Jochen Kupper, Aleksandar Milivojevic, Xavier Maillard, Greg Sabino Mullane, Thomas Roessler, Moritz Schulte, Thomas Sjogren, Paul Walker, and Steve Youngs. No doubt the list is incomplete. We apologize to anyone we left out. 8. Security Considerations These headers are intended to be a convenience in locating public keys: They are neither secure nor intended to be. Since header information is easy to spoof, information contained in headers should not be trusted: The information must be verified. How the information is verified is left as an exercise for the reader. Applications that interpret the data within this header MUST NOT assume that the data is correct, and MUST NOT present the data to the user in any way that would cause the user to assume that it is correct. Applications that interpret the data within this header SHOULD alert the user that this information is not a substitute for personally verifying keys and being a part of the web of trust. If an application receives a signed message and uses the information in this header to retrieve a key, the application MAY ignore the retrieved key if it is not the same key used to sign the message. Smasher & Josefsson Expires July 8, 2005 [Page 7] Internet-Draft The OpenPGP mail and news header January 2005 This SHOULD be done before the newly retrieved key is imported into the user's keyring. The use of HTTPS [12], DNSSEC [9], SMTP STARTTLS [10], and other secure protocols, may enhance the security of information conveyed through this header, but does not guarantee any level of security or authenticity. Developers and users must remain aware of this. Given the flexibility of the syntax of the header, slightly varying the content between messages can be used as a covert channel. 9. Copying conditions In addition to the IETF/ISOC copying conditions, the following statement grant third parties further rights to this document. Copyright (C) 2004 Atom Smasher Copyright (C) 2004, 2005 Simon Josefsson Copying and distribution of the work, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. 10. References 10.1 Normative References [1] Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [5] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [6] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 10.2 Informative References [7] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, Smasher & Josefsson Expires July 8, 2005 [Page 8] Internet-Draft The OpenPGP mail and news header January 2005 RFC 959, October 1985. [8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [9] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [10] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999. [11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [13] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. Authors' Addresses Atom Smasher EMail: atom@smasher.org (0x762A3B98A3C396C9C6B7582AB88D52E4D9F57808) Simon Josefsson EMail: simon@josefsson.org (0x0424D4EE81A0E3D119C6F835EDA21E94B565716F) Smasher & Josefsson Expires July 8, 2005 [Page 9] Internet-Draft The OpenPGP mail and news header January 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Smasher & Josefsson Expires July 8, 2005 [Page 10]