I'll be attempting to formally submit some "OpenPGP-*" mail & news header definitions to IETF. I'd like to first submit this *rough* draft here. Please send comments to 0. 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 and netnews messages. This header should be used to provide information about the sender's OpenPGP key. This header MAY be used in any message. This document should be interpreted within the context of RFC2822. In the event of a discrepancy, refer to that document. 1. "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: The structure consisting of several name/value pairs (as defined below). One or more name/value pairs may be used within this header. This header SHOULD NOT appear more than once within a message. 2. Name/Value Pairs Each name/value pair pair MUST be presented in the format: name=value A value MUST NOT contain white space characters. 2.1. Multiple Name/Value Pairs If more than one name/value pair is used within this header, they MUST be separated by a semi-colon and space. The following are valid examples of multiple name/value pairs used within this header: name1=value1; name2=value2 name1=value1; name2=value2; name3=value3 2.2. Comments Each name/value pair MAY be followed by one or more white space characters and a human readable comment. A comment, if used, MUST be contained within parentheses "()". Comments are not intended to be interpreted by any application. The following are valid examples of comments used within this header: name=value (comment) name1=value1 (comment1); name2=value2 name1=value1; name2=value2 (comment2) name1=value1 (comment1); name2=value2 (comment2) 3. Name/Value Pairs, Defined 3.1. Primary Key ID (id) This name/value pair, if present, MUST define the primary key ID. The key ID SHOULD be prefixed with "0x", and MUST be identified as "id=???", where "???" is the hexadecimal key ID or fingerprint. The key ID MUST be presented in either short, long or fingerprint hexadecimal notation (described below). A short key ID is a 32 bit key ID, represented as 8 hexadecimal characters. A long key ID is a 64 bit key ID, represented as 16 hexadecimal characters. A v4 fingerprint is a 160 bit key ID, represented as 40 hexadecimal characters. A v3 fingerprint is a 128 bit key ID, represented as 32 hexadecimal characters. 3.1.1. Examples Note that each of these examples includes a comment, which is optional. id=0x12345678 (short key ID) id=0x1234567890ABCDEF (long key ID) id=0x1234567890ABCDEF01234567890ABCDEF0123456 (v4 fingerprint) id=0x1234567890ABCDEF01234567890ABCDE (v3 fingerprint) 3.2. Primary Key Algorithm (algo) This name/value pair, if present, MUST define the algorithm of the primary key. The algorithm of the primary key MUST be presented as "algo=???", where "???" is the algorithm id number as defined in RFC2440:9.1 (Public Key Algorithms). The value MUST be presented as an integer in decimal notation. 3.2.1. Examples Note that each of these examples includes a comment, which is optional. algo=1 (RSA) algo=17 (DSA) 3.3. Primary Key Size (size) This name/value pair, if present, MUST define the size of the primary key. The size of the primary key MUST be presented as "size=???", where "???" is the number of bits in the key's modulus. The value MUST be presented as an integer in decimal notation. 3.3.1. Examples size=1024 size=2048 3.4. Key URL (url) This name/value pair, if present, MUST define an HTTP, HTTPS or FTP URL where the public key can be found. The URL MUST be presented as "url=???", where "???" is the URL where the key can be found. The URL MUST be fully qualified and SHOULD be accessible on the public Internet. 3.4.1. Example url=http://atom.smasher.org/pgp.txt 4. 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) 5. Motivation For Proposing This Standard There are quite a few PGP & GnuPG users who add these types of headers, but they lack standardization, making them useless to automatically parse. Since both PGP and GnuPG rely on the OpenPGP protocol (RFC 2440), it seems best to use headers that specify "OpenPGP" rather than "PGP", or "GPG": The latter forms appear as underhanded attempts to advocate specific applications, rather than the open standard they both share. 6. 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 SHOULD notify the user whether or not the retrieved key is the same key used to sign the message. This SHOULD be done before the newly retrieved key is imported into the user's keyring. The use of HTTPS, DNSSEC, SMTP-TLS 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. 6. References RFC2119 - Key words for use in RFCs to Indicate Requirement Levels RFC2822 - Internet Message Format RFC2440 - OpenPGP Message Format draft 0.2 Wed Aug 11 03:20:04 EDT 2004