One document matched: draft-josefsson-openpgp-mailnews-header-06.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<rfc category="info" ipr="full3978"
docName="draft-josefsson-openpgp-mailnews-header-06">
<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="May" 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
appears 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 or other messages. 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
trust-worthy.</t>
<t>This document neither suggests a specific scenario of when
the field should be used, nor how it should be used. 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 arises during handling of
the OpenPGP field. It is generally recommended that an
implementation ignore the presence of an OpenPGP field if it
would cause an error condition. 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
typically contains the Key ID and the URL where the key can be
retrieved.</t>
<t>Because the mail 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 in 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
parameters may be quoted; whitespace, folding and comments may
occur in the middle of parameters; except as noted below. The
provisions of <xref target="RFC2231" >MIME Parameter
Extensions</xref> also apply; in particular, that document
deals with handling parameters of excessive length.</t>
<t>The OpenPGP header field is defined below in
the <xref target="RFC5234">Augmented BNF</xref> notation. By
itself, however, this grammar is incomplete. It refers by
name to syntax rules that are defined in
<xref target="RFC2822" /> and <xref target="RFC3986" />.
Rather than reproduce those definitions here, and risk
unintentional differences between the two, this document
refers the reader to the other documents for the definition of
non-terminals.</t>
<t>Implementations MUST understand the "id", "url", and
"preference" attributes. Parameter with unrecognized
attributes MUST be ignored. The grammar permits unknown
parameters to allow for future extensions. Each parameter
attribute (e.g., "url") MUST NOT occur more than once in any
single instance of the OpenPGP field. The OpenPGP field
itself MAY occur more than once in a single email (for example
if the sender has multiple keys).</t>
<figure>
<artwork type="abnf">
openpgp = "OpenPGP:" SP o-params CRLF
; CFWS is defined in RFC 2822.
; SP and CRLF are defined in RFC 5234.
o-params = (o-parameter *(";" o-parameter))
o-parameter = *CFWS "id" "=" id *CFWS
/ *CFWS "url" "=" url *CFWS
/ *CFWS "preference" "=" preference *CFWS
/ *CFWS parameter *CFWS ; normally unused, for extensions
; parameter is defined in RFC 2045.
id = 1*(8HEXDIG)
; HEXDIG is defined in RFC 5234.
; Matching of value is case-insensitive.
url = absoluteURI / quoted-url
; absoluteURI is defined in RFC 3986.
; If the URL contains the character ";",
; the quoted-url form MUST be used.
quoted-url = DQUOTE absoluteURI DQUOTE
; DQUOTE is defined in RFC 5234.
preference = "sign" / "encrypt" / "signencrypt" / "unprotected"
; Matching of values is case-insensitive.
</artwork>
</figure>
<section title="Primary Key ID field: id">
<t>The "id" parameter, if present, MUST hold the Key ID or key
fingerprint for the primary key. The value uses
the <xref target="RFC4648">hex</xref> notation. The
parameter value is case-insensitive.</t>
<t>The length of the field determines whether it denotes a Key
ID (8 hex symbols), a long Key ID (16 hex symbols), a v3 key
fingerprint (32 hex symbols), or a v4 key fingerprint (40
hex symbols).</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=1234567890abcdef0123456789ABCDEF01234567 (v4 fingerprint)
id=1234567890ABCDEF0123456789ABCDEF (v3 fingerprint, deprecated)
</artwork>
</figure>
</section>
<section title="Key URL field: url">
<t>The "url" parameter, 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>The content of where the URL points SHOULD be either an
ASCII armored or binary OpenPGP packet containing the key.
A valid reason for storing something else may be if the key
has been revoked.</t>
<t>For example:</t>
<figure>
<artwork>
url=http://example.org/pgp.txt
url="http://example.org/funny;name.txt"
</artwork>
</figure>
<t>If the URL contains the character ';' the entire URL MUST
be quoted, as illustrated in the example.</t>
</section>
<section title="Protection Preference Field: preference">
<t>The "preference" parameter, if present, specify the quality
of protection preferred by the sender. The parameter value
is case-insensitive.</t>
<t>The available values are as follows. A "unprotected" token
means that the sender prefers not to receive OpenPGP
protected e-mails. A "sign" token means that the sender
prefers to receive digitally signed e-mails. A "encrypt"
token means that the sender prefers to receive encrypted
e-mails. A "signencrypt" token means that the sender
prefers to receive encrypted and signed e-mails.</t>
<t>Note that there is no normative 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 to 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)
OpenPGP: id=12345678; url="http://example.com/openpgp;key.txt"
</artwork>
</figure>
</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, Alfred Hoenes, Peter J. Holzer, Ingo
Klocker, Werner Koch, Jochen Kupper, William Leibzon, Charles
Lindsey, Aleksandar Milivojevic, Xavier Maillard, Greg Sabino
Mullane, Tim Polk, 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; it is 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 automatically 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
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.</t>
<t>If an attacker wants to check the validity of email
addresses, he might email arbitrary addresses with a unique
OpenPGP header field URL (presumably an URL under the
attacker's control). The attacker can verify the liveness of
each email address by checking if the URL for each particular
recipient has been retrieved. 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. This is already possible using other header fields
in email, and thus the OpenPGP field does not introduce a new
vulnerability here.</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>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2045.xml"?>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.2231.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>
<section title="Copying conditions">
<t>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.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 18:06:11 |