One document matched: draft-josefsson-openpgp-mailnews-header-04.txt
Differences from draft-josefsson-openpgp-mailnews-header-03.txt
Network Working Group A. Smasher
Internet-Draft S. Josefsson
Intended status: Informational April 2, 2008
Expires: October 4, 2008
The OpenPGP mail and news header field
draft-josefsson-openpgp-mailnews-header-04
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 October 4, 2008.
Abstract
This document describes the OpenPGP mail and news header field. The
field provide information about the sender's OpenPGP key.
See <http://josefsson.org/openpgp-header/> for more information.
Smasher & Josefsson Expires October 4, 2008 [Page 1]
Internet-Draft The OpenPGP mail and news header field April 2008
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. Key URL field: url . . . . . . . . . . . . . . . . . . . . 5
3.3. Protection Preference Field: preference . . . . . . . . . 6
4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Smasher & Josefsson Expires October 4, 2008 [Page 2]
Internet-Draft The OpenPGP mail and news header field April 2008
1. Preface
This document is intended to define the "OpenPGP" message header
field. This field should be considered "informational" (and
"optional"), and be suitable for both mail [RFC2822] and netnews
[RFC1036] messages. This field should be used to provide information
about the sender's OpenPGP [RFC4880] key. This field 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 [RFC2119].
2. Background and Motivation
There are quite a few PGP and GnuPG users who add header fields with
information about the sender's OpenPGP key. Fields in current use
include "X-PGP:", "X-PGP-Key:", "X-Request-PGP:", "X-PGP-KeyID:", and
"X-PGP-Fingerprint:". The fields are not standardized, so they
cannot be reliably parsed automatically by applications, only 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 field name. The latter forms appear as underhanded attempts to
advocate specific applications, rather than the open standard they
both share. The field specified here is named "OpenPGP".
The OpenPGP field 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
the field. Consequently, the information in the field should not
disrupt the normal OpenPGP key retrieval and web of trust mechanism.
Neither the integrity nor the authenticity of the information in the
field should be assumed to be correct or be trust-worthy.
No specific scenario when the field 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 the field
may be by humans and not applications.
To promote good use of the field, 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 field.
Smasher & Josefsson Expires October 4, 2008 [Page 3]
Internet-Draft The OpenPGP mail and news header field April 2008
It is generally recommended that an implementation ignore the
presence of the OpenPGP fields if an error condition occur. Since
the field 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
The OpenPGP header field is intended to present characteristics of
the sender's OpenPGP key. The field may contain the Key ID and the
URL where the key can be retrieved.
Because the header is typically not integrity protected, the
information conveyed in the OpenPGP header field MUST NOT be trusted
without additional verification. Some of the information given in
this field may also be given on the OpenPGP key itself. When these
two sources conflict, users SHOULD favor the information from the
OpenPGP key, as that information can be cryptographically protected.
The field is of a "structured" type (see section 2.2.2 of RFC 2822).
In general, the structure consist of one or more parameters, each
consisting of one attribute and one value. The terminology and
format of the field was inspired by MIME [RFC2045]. The various
provisions of RFC 2045 apply. In particular, the value part of
parameters may be quoted; whitespace, folding and comments may occur
in the middle of parameters. The provisions of MIME [RFC2231] also
apply; in particular it deals with handling parameters of excessive
length.
The OpenPGP header field is defined as below in the Augmented BNF
[RFC5234] notation. By itself, however, this grammar is incomplete.
It refers by name to syntax rules that are defined in [RFC2822] and
[RFC3986]. Rather than reproduce those definitions here, and risk
unintentional differences between the two, this document refer the
reader to the other documents for the definition of non-terminals.
Unrecognized parameters MUST be ignored. The grammar permit them to
allow for future extensions. A given parameter type (i.e., "id",
"url" or "preference") MUST NOT occur more than once. The OpenPGP:
field itself SHOULD NOT appear more than once within a message.
Smasher & Josefsson Expires October 4, 2008 [Page 4]
Internet-Draft The OpenPGP mail and news header field April 2008
openpgp = "OpenPGP:" SP *CFWS openpgp-params *CFWS CRLF
; CFWS is defined in RFC 2822.
openpgp-params
= (openpgp-parameter *(";" *CFWS openpgp-parameter))
openpgp-parameter
= ("id" "=" id) /
("url" "=" url) /
("preference" "=" preference) /
parameter ; See RFC 2045 for definition of parameter.
id = 8*HEXDIG ; Defined in RFC 5234.
url = absoluteURI ; Defined in RFC 3986.
preference = "sign" / "encrypt" / "signencrypt" / "unprotected"
3.1. Primary Key ID field: id
The "id" attribute=value pair, if present, MUST define the primary
key ID. The value MUST identify the key ID (in either short or long
form) or the fingerprint, all using the hex [RFC4648] notation.
The length of the field imply the kind of key id, i.e., short or long
form, or a v3 or v4 key.
Note that each of the following examples includes a comment, which is
optional.
id=12345678 (short key ID)
id=1234567890ABCDEF (long key ID)
id=1234567890abcdef01234567890ABCDEF0123456 (v4 fingerprint)
id=1234567890ABCDEF01234567890ABCDE (v3 fingerprint, deprecated)
3.2. 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 [RFC2616] or FTP [RFC0959]. 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
Smasher & Josefsson Expires October 4, 2008 [Page 5]
Internet-Draft The OpenPGP mail and news header field April 2008
3.3. Protection Preference Field: preference
The "preference" attribute=value pair, if present, specify the
quality of protection preferred by the sender. The available choices
are "unprotected" which means that the sender prefer not to receive
OpenPGP protected e-mails. A "sign" token means that the sender
prefer to receive digitally signed e-mails. A "encrypt" token means
that the sender prefer to receive digitally encrypted e-mails. A
"signencrypt" token means that the sender prefer to receive digitally
encrypted and signed e-mails. Note that there is no technical
requirement on the receiver to follow the stated preference.
For example:
preference=sign
preference="unprotected"
preference=ENCRYPT
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 OpenPGP fields with comments:
id=B565716F (key stored on non-networked laptop)
id=12345678 (1024 bit RSA Key for Encrypt or Sign)
id=ABCD0123 (created Sun Jan 2 02:25:15 CET 2005)
5. Examples
These are valid examples of how the field may be used. This list is
not meant to be exhaustive, but do reflect expected typical usages.
OpenPGP: id=12345678
OpenPGP: url=http://example.com/key.txt
OpenPGP: preference=unprotected
OpenPGP: url=http://example.com/key.txt; id=12345678
OpenPGP: id=12345678; url=http://example.com/key.txt;
preference=signencrypt
OpenPGP: url=http://example.com/key.txt (down 2-3pm UTC);
id=12345678 (this key is only used at the office);
preference=sign (unsigned emails are filtered away)
Smasher & Josefsson Expires October 4, 2008 [Page 6]
Internet-Draft The OpenPGP mail and news header field April 2008
6. Acknowledgements
The content of this document builds on discussions with (in
alphabetical order) Christian Biere, Patrick Brunschwig, Jon Callas,
Dave Evans, Peter J. Holzer, Ingo Klocker, Werner Koch, Jochen
Kupper, William Leibzon, Charles Lindsey, Aleksandar Milivojevic,
Xavier Maillard, Greg Sabino Mullane, Thomas Roessler, Moritz
Schulte, Olav Seyfarth, David Shaw, Thomas Sjogren, Paul Walker, and
Steve Youngs. No doubt the list is incomplete. We apologize to
anyone we left out.
7. Security Considerations
The OpenPGP header field is intended to be a convenience in locating
public keys. They are neither secure nor intended to be. Since the
message header is easy to spoof, information contained in the header
should not be trusted. The information must be verified.
Applications that interpret the field MUST NOT assume that the
content 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 the field 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 the field to retrieve a key, the application MAY ignore the
retrieved key if it is not 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 [RFC2818], DNSSEC [RFC4033], SMTP STARTTLS
[RFC3207], IMAP/POP3 STARTTLS [RFC2595] and other secure protocols,
may enhance the security of information conveyed through this field,
but does not guarantee any level of security or authenticity.
Developers and users must remain aware of this.
Version 3 OpenPGP keys can be created with a chosen key id (aka "the
0xDEADBEEF attack"). Verifying the Key ID of a retrieved key against
the one provided in the field is thus not sufficient to protect
against a man-in-the-middle attack. Instead, the web-of-trust
mechanism should be used.
If an attacker wants to check the validity of Email addresses, he
might send out junk email to arbitrary addresses and collect those
that report back to the crafted OpenPGP URL. To protect against
this, implementations MUST inform the user of that potential privacy
Smasher & Josefsson Expires October 4, 2008 [Page 7]
Internet-Draft The OpenPGP mail and news header field April 2008
issue when retrieving keys from an URL provided by the field of an
inbound email message: either when the feature is enabled or to be
used for the first time or every time the MUA detects an unknown key.
Given the flexibility of the syntax of the field, slightly varying
the content between messages can be used as a covert channel.
8. IANA Considerations
The IANA is asked to register the OpenPGP header field, using the
template as follows, in accordance with RFC 3864 [RFC3864].
Header field name: OpenPGP
Applicable protocol: mail, netnews
Status: informational
Author/Change controller: IETF
Specification document(s): This document.
Related information: None
Smasher & Josefsson Expires October 4, 2008 [Page 8]
Internet-Draft The OpenPGP mail and news header field April 2008
9. Copying conditions
Regarding this entire document or any portion of it, the authors
makes no guarantees and is not responsible for any damage resulting
from its use. The authors grants irrevocable permission to anyone to
use, modify, and distribute it in any way that does not diminish the
rights of anyone else to use, modify, and distribute it, provided
that redistributed derivative works do not contain misleading author
or version information. Derivative works need not be licensed under
similar terms.
10. References
10.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions:
Character Sets, Languages, and Continuations", RFC 2231,
November 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
10.2. Informative References
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985.
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of
USENET messages", RFC 1036, December 1987.
Smasher & Josefsson Expires October 4, 2008 [Page 9]
Internet-Draft The OpenPGP mail and news header field April 2008
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, June 1999.
[RFC2616] 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.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
Authors' Addresses
Atom Smasher
Email: atom@smasher.org (762A3B98A3C396C9C6B7582AB88D52E4D9F57808)
Simon Josefsson
Email: simon@josefsson.org (0424D4EE81A0E3D119C6F835EDA21E94B565716F)
Smasher & Josefsson Expires October 4, 2008 [Page 10]
Internet-Draft The OpenPGP mail and news header field April 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Smasher & Josefsson Expires October 4, 2008 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-21 18:28:45 |