One document matched: draft-josefsson-openpgp-mailnews-header-03.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<rfc category="info" ipr="full3978"
docName="draft-josefsson-openpgp-mailnews-header-03">
<front>
<title>
The OpenPGP mail and news header field
</title>
<author initials="A." surname="Smasher" fullname="Atom Smasher">
<organization></organization>
<address>
<email>atom@smasher.org
(762A3B98A3C396C9C6B7582AB88D52E4D9F57808)</email>
</address>
</author>
<author initials="S." surname="Josefsson" fullname="Simon Josefsson">
<organization></organization>
<address>
<email>simon@josefsson.org
(0424D4EE81A0E3D119C6F835EDA21E94B565716F)</email>
</address>
</author>
<date month="February" year="2008"/>
<abstract>
<t>This document describes the OpenPGP mail and news header
field. The field provide information about the sender's
OpenPGP key.</t>
<t>See <http://josefsson.org/openpgp-header/> for more
information.</t>
</abstract>
</front>
<middle>
<section title="Preface">
<t>This document is intended to define the "OpenPGP" message
header field. This field should be considered "informational"
(and "optional"), and be suitable for both
<xref target="RFC2822">mail</xref>
and <xref target="RFC1036">netnews</xref> messages. This
field should be used to provide information about the
sender's <xref target="RFC4880">OpenPGP</xref> key. This
field MAY be used in any message.</t>
<t>This document should be interpreted within the context of RFC
2822. In the event of a discrepancy, refer to that
document.</t>
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Background and Motivation">
<t>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.</t>
<t>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".</t>
<t>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.</t>
<t>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.</t>
<t>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. 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.</t>
</section>
<section title="OpenPGP Header Field">
<t>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.</t>
<t>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.</t>
<t>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 <xref target="RFC2045">MIME</xref>. The various provisions
of RFC 2045 apply. In particular, the value part of all
parameters may be quoted; whitespace, foldoing and comments
may occur in the middle of parameters. The provisions
of <xref target="RFC2231">MIME</xref> also apply; in
particular it deals with handling parameters of excessive
length.</t>
<t>In the <xref target="RFC5234">Augmented BNF</xref> notation,
the 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 <xref target="RFC3986">URI syntax document</xref>. Rather
than reproduce those definitions here, and risk unintentional
differences between the two, this document refer the reader to
RFC 2822 and RFC 3986 for the definition of non-terminals.</t>
<t>Unrecognized parameters MUST be ignored. The grammar permit
them to allow for future extensions. The field SHOULD NOT
appear more than once within a message. A given parameter
type (i.e., "id", "url" or "preference") MUST NOT occur more
than once.</t>
<figure>
<artwork>
openpgp := "OpenPGP:"
(openpgp-parameter *(";" openpgp-parameter))
CRLF
id := 8*HEXDIG
url := absoluteURI ; Defined in RFC 3986.
preference := "sign" / "encrypt" / "signencrypt" / "unprotected"
openpgp-parameter
:= ("id" "=" id) /
("url" "=" url) /
("preference" "=" preference) /
parameter ; See RFC 2045 for definition of parameter.
</artwork>
</figure>
<section title="Primary Key ID field: id">
<t>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 <xref target="RFC4648">hex</xref> notation.</t>
<t>The length of the field imply the kind of key id, i.e.,
short or long form, or a v3 or v4 key.</t>
<t>Note that each of the following examples includes a
comment, which is optional.</t>
<figure>
<artwork>
id=12345678 (short key ID)
id=1234567890ABCDEF (long key ID)
id=1234567890abcdef01234567890ABCDEF0123456 (v4 fingerprint)
id=1234567890ABCDEF01234567890ABCDE (v3 fingerprint, deprecated)
</artwork>
</figure>
</section>
<section title="Key URL field: url">
<t>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 <xref target="RFC2616">
HTTP</xref> or <xref target="RFC0959">FTP</xref>. The URL
MUST be fully qualified, MUST explicitly specify a protocol
and SHOULD be accessible on the public Internet.</t>
<t>For example:</t>
<figure>
<artwork>
url=http://example.org/pgp.txt
</artwork>
</figure>
</section>
<section title="Protection Preference Field: preference">
<t>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.</t>
<t>For example:</t>
<figure>
<artwork>
preference=sign
preference="unprotected"
preference=ENCRYPT
</artwork>
</figure>
</section>
</section>
<section title="Comments">
<t>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.</t>
<t>The following are examples of OpenPGP fields with
comments:</t>
<figure>
<artwork>
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)
</artwork>
</figure>
</section>
<section title="Examples">
<t>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.</t>
<figure>
<artwork>
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)
</artwork>
</figure>
</section>
<section title="Open Issues">
<t>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? This draft tentatively closes this issue by
ignoring the matter, until someone proposes text.</t>
<t>The ABNF definition is known to be under-specified.</t>
</section>
<section title="Acknowledgements">
<t>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.</t>
</section>
<section title="Security Considerations">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>The use of <xref target="RFC2818">HTTPS</xref>,
<xref target="RFC4033">DNSSEC</xref>,
<xref target="RFC3207">SMTP
STARTTLS</xref>, <xref target="RFC2595">IMAP/POP3
STARTTLS</xref> 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.</t>
<t>Version 3 OpenPGP keys can be created with a chosen key id
(aka "the 0xDEADBEEF attack"). Verifying the Key ID of a
retrived 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.</t>
<t>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 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.</t>
<t>Given the flexibility of the syntax of the field, slightly
varying the content between messages can be used as a covert
channel.</t>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>The IANA is asked to register the OpenPGP header field, using
the template as follows, in accordance
with <xref target="RFC3864">RFC 3864</xref>.</t>
<t>Header field name: OpenPGP</t>
<t>Applicable protocol: mail, netnews</t>
<t>Status: informational</t>
<t>Author/Change controller: IETF</t>
<t>Specification document(s): This document.</t>
<t>Related information: None</t>
<t><vspace blankLines="10000" /></t>
</section>
<section title="Copying conditions">
<t>In addition to the IETF/ISOC copying conditions, the
following statement grant third parties further rights to this
document.</t>
<figure>
<artwork>
Copyright (C) 2004 Atom Smasher
Copyright (C) 2004, 2005 Simon Josefsson
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.
</artwork>
</figure>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2045.xml"?>
<?rfc include="reference.RFC.2231.xml"?>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.2822.xml"?>
<?rfc include="reference.RFC.3986.xml"?>
<?rfc include="reference.RFC.4880.xml"?>
<?rfc include="reference.RFC.5234.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0959.xml"?>
<?rfc include="reference.RFC.1036.xml"?>
<?rfc include="reference.RFC.2595.xml"?>
<?rfc include="reference.RFC.2616.xml"?>
<?rfc include="reference.RFC.2818.xml"?>
<?rfc include="reference.RFC.3207.xml"?>
<?rfc include="reference.RFC.3864.xml"?>
<?rfc include="reference.RFC.4033.xml"?>
<?rfc include="reference.RFC.4648.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 18:12:44 |