draft-josefsson-openpgp-mailnews-header-02.txt   draft-josefsson-openpgp-mailnews-header-03.txt 
Network Working Group A. Smasher Network Working Group A. Smasher
Internet-Draft S. Josefsson Internet-Draft S. Josefsson
Expires: March 27, 2006 September 23, 2005 Intended status: Informational February 23, 2008
Expires: August 26, 2008
The OpenPGP mail and news header The OpenPGP mail and news header field
draft-josefsson-openpgp-mailnews-header-02 draft-josefsson-openpgp-mailnews-header-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 27, 2006. This Internet-Draft will expire on August 26, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes the OpenPGP mail and news header field. The This document describes the OpenPGP mail and news header field. The
field provide information about the sender's OpenPGP key. field provide information about the sender's OpenPGP key.
See <http://josefsson.org/openpgp-header/> for more information. See <http://josefsson.org/openpgp-header/> for more information.
Table of Contents Table of Contents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 9 10. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 11
1. Preface 1. Preface
This document is intended to define the "OpenPGP" message header. This document is intended to define the "OpenPGP" message header
This header should be considered "informational" (and "optional"), field. This field should be considered "informational" (and
and be suitable for both mail [8] and netnews [1] messages. This "optional"), and be suitable for both mail [4] and netnews [9]
header should be used to provide information about the sender's messages. This field should be used to provide information about the
OpenPGP [7] key. This header MAY be used in any message. sender's OpenPGP [6] key. This field MAY be used in any message.
This document should be interpreted within the context of RFC 2822. This document should be interpreted within the context of RFC 2822.
In the event of a discrepancy, refer to that document. In the event of a discrepancy, refer to that document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4]. document are to be interpreted as described in RFC 2119 [3].
2. Background and Motivation 2. Background and Motivation
There are quite a few PGP and GnuPG users who add headers with There are quite a few PGP and GnuPG users who add header fields with
information about the sender's OpenPGP key. Headers in current use information about the sender's OpenPGP key. Fields in current use
include "X-PGP:", "X-PGP-Key:", "X-Request-PGP:", "X-PGP-KeyID:", and include "X-PGP:", "X-PGP-Key:", "X-Request-PGP:", "X-PGP-KeyID:", and
"X-PGP-Fingerprint:". The headers lack standardization, which "X-PGP-Fingerprint:". The fields are not standardized, so they
prevent them from being reliably parsed automatically by cannot be reliably parsed automatically by applications, only parsed
applications, rather than manually parsed by humans. by humans.
Since both PGP and GnuPG rely on the OpenPGP protocol, it appear Since both PGP and GnuPG rely on the OpenPGP protocol, it appear
preferable to use the term "OpenPGP" rather than "PGP", or "GPG", in preferable to use the term "OpenPGP" rather than "PGP", or "GPG", in
the header name. The latter forms appear as underhanded attempts to the field name. The latter forms appear as underhanded attempts to
advocate specific applications, rather than the open standard they advocate specific applications, rather than the open standard they
both share. The header specified here is named "OpenPGP". both share. The field specified here is named "OpenPGP".
The OpenPGP header is not a required part of successful use of The OpenPGP field is not a required part of successful use of OpenPGP
OpenPGP in e-mail. It is intended as a convenience, in those in e-mail. It is intended as a convenience, in those situations
situations where the user experience may be enhanced by using the where the user experience may be enhanced by using the information in
information in this header. Consequently, the information in this the field. Consequently, the information in the field should not
header should not disrupt the normal OpenPGP key retrieval and web of disrupt the normal OpenPGP key retrieval and web of trust mechanism.
trust mechanism. Neither the integrity nor the authenticity of the Neither the integrity nor the authenticity of the information in the
information in this header should be assumed to be correct or be field should be assumed to be correct or be trust-worthy.
trust-worthy.
No specific scenario when the header should be used, nor how it No specific scenario when the field should be used, nor how it should
should be used in that scenario, are suggested by this document. It be used in that scenario, are suggested by this document. It is
is acknowledged that the dominant use of the information in this acknowledged that the dominant use of the information in the field
header may be by humans and not applications. may be by humans and not applications.
To promote good use of this header, care should be taken so that To promote good use of the field, care should be taken so that
applications do not trigger error messages that may annoy the user, applications do not trigger error messages that may annoy the user,
when an error condition arise during handling of the OpenPGP header. when an error condition arise during handling of the OpenPGP field.
It is generally recommended that an implementation ignore the It is generally recommended that an implementation ignore the
presence of the OpenPGP header if an error condition occur. Since presence of the OpenPGP fields if an error condition occur. Since
the header is optional, this approach should not be difficult to the field is optional, this approach should not be difficult to
implement. The philosophy here is to enable an enhanced user implement. The philosophy here is to enable an enhanced user
experience. Error messages rarely contribute to that goal. experience. Error messages rarely contribute to that goal.
3. OpenPGP Header Field 3. OpenPGP Header Field
This header is intended to present characteristics of the sender's The OpenPGP header field is intended to present characteristics of
OpenPGP key. It may contain the Key ID and the URL where the key can the sender's OpenPGP key. The field may contain the Key ID and the
be retrieved. URL where the key can be retrieved.
This header is of a "structured" type (see section 2.2.2 of RFC Because the header is typically not integrity protected, the
2822). In general, the structure consist of one or more parameters, information conveyed in the OpenPGP header field MUST NOT be trusted
each consisting of one attribute and one value. The terminology and without additional verification. Some of the information given in
format of the header was inspired by MIME [2]. The various this field may also be given on the OpenPGP key itself. When these
provisions of RFC 2045 apply. In particular, the value part of all two sources conflict, users SHOULD favor the information from the
parameters may be quoted; whitespace, foldoing and comments may occur OpenPGP key, as that information can be cryptographically protected.
in the middle of parameters. The provisions of MIME [3] also apply;
in particular it deals with handling parameters of excessive length.
In the Augmented BNF [5] notation, an OpenPGP header field is defined The field is of a "structured" type (see section 2.2.2 of RFC 2822).
as below. By itself, however, this grammar is incomplete. It refers In general, the structure consist of one or more parameters, each
by name to several syntax rules that are defined by RFC 2822 and the consisting of one attribute and one value. The terminology and
URI syntax document [6]. Rather than reproduce those definitions format of the field was inspired by MIME [1]. The various provisions
here, and risk unintentional differences between the two, this of RFC 2045 apply. In particular, the value part of all parameters
document refer the reader to RFC 2822 and RFC 2396 for the definition may be quoted; whitespace, foldoing and comments may occur in the
of non-terminals. middle of parameters. The provisions of MIME [2] also apply; in
particular it deals with handling parameters of excessive length.
In the Augmented BNF [7] 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 URI syntax document [5]. 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.
Unrecognized parameters MUST be ignored. The grammar permit them to Unrecognized parameters MUST be ignored. The grammar permit them to
allow for future extensions. This header SHOULD NOT appear more than allow for future extensions. The field SHOULD NOT appear more than
once within a message. A given parameter type (i.e., "id", "url" or once within a message. A given parameter type (i.e., "id", "url" or
"preference") MUST NOT occur more than once. "preference") MUST NOT occur more than once.
openpgp := "OpenPGP:" openpgp := "OpenPGP:"
(openpgp-parameter *(";" openpgp-parameter)) (openpgp-parameter *(";" openpgp-parameter))
CRLF CRLF
id := *HEXDIG id := 8*HEXDIG
url := absoluteURI ; Defined in RFC 2396. url := absoluteURI ; Defined in RFC 3986.
preference := "sign" / "encrypt" / "signencrypt" / "unprotected" preference := "sign" / "encrypt" / "signencrypt" / "unprotected"
openpgp-parameter openpgp-parameter
:= ("id" "=" id) / := ("id" "=" id) /
("url" "=" url) / ("url" "=" url) /
("preference" "=" preference) / ("preference" "=" preference) /
parameter ; See RFC 2045 for definition of parameter. parameter ; See RFC 2045 for definition of parameter.
3.1. Primary Key ID field: id 3.1. Primary Key ID field: id
The "id" attribute=value pair, if present, MUST define the primary 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 key ID. The value MUST identify the key ID (in either short or long
form) or the fingerprint, all using the hexadecimal [14] notation. form) or the fingerprint, all using the hex [16] notation.
The length of the field imply the kind of key id, i.e., short or long The length of the field imply the kind of key id, i.e., short or long
form, or a v3 or v4 key. form, or a v3 or v4 key.
Note that each of the following examples includes a comment, which is Note that each of the following examples includes a comment, which is
optional. optional.
id=12345678 (short key ID) id=12345678 (short key ID)
id=1234567890ABCDEF (long key ID) id=1234567890ABCDEF (long key ID)
id=1234567890abcdef01234567890ABCDEF0123456 (v4 fingerprint) id=1234567890abcdef01234567890ABCDEF0123456 (v4 fingerprint)
id=1234567890ABCDEF01234567890ABCDE (v3 fingerprint, deprecated) id=1234567890ABCDEF01234567890ABCDE (v3 fingerprint, deprecated)
3.2. Key URL field: url 3.2. Key URL field: url
The "url" attribute=value pair, if present, MUST specify a URL where 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 the public key can be found. It is RECOMMENDED to use a common URL
family, such as HTTP [12] or FTP [9]. The URL MUST be fully family, such as HTTP [11] or FTP [8]. The URL MUST be fully
qualified, MUST explicitly specify a protocol and SHOULD be qualified, MUST explicitly specify a protocol and SHOULD be
accessible on the public Internet. accessible on the public Internet.
For example: For example:
url=http://example.org/pgp.txt url=http://example.org/pgp.txt
3.3. Protection Preference Field: preference 3.3. Protection Preference Field: preference
The "preference" attribute=value pair, if present, specify the The "preference" attribute=value pair, if present, specify the
skipping to change at page 6, line 29 skipping to change at page 6, line 29
preference=sign preference=sign
preference="unprotected" preference="unprotected"
preference=ENCRYPT preference=ENCRYPT
4. Comments 4. Comments
As discussed in section 3.2.3 of RFC 2822, comments may appear in 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 header field bodies. Comments are not intended to be interpreted by
any application, but to provide additional information for humans. any application, but to provide additional information for humans.
The following are examples of header field bodies with comments: The following are examples of OpenPGP fields with comments:
id=B565716F (key stored on non-networked laptop) id=B565716F (key stored on non-networked laptop)
id=12345678 (1024 bit RSA Key for Encrypt or Sign) id=12345678 (1024 bit RSA Key for Encrypt or Sign)
id=ABCD0123 (created Sun Jan 2 02:25:15 CET 2005) id=ABCD0123 (created Sun Jan 2 02:25:15 CET 2005)
5. Examples 5. Examples
These are valid examples of ways in which this header may be used. These are valid examples of how the field may be used. This list is
This list is not meant to be exhaustive, but do reflect expected not meant to be exhaustive, but do reflect expected typical usages.
typical usages.
OpenPGP: id=12345678 OpenPGP: id=12345678
OpenPGP: url=http://example.com/key.txt OpenPGP: url=http://example.com/key.txt
OpenPGP: preference=unprotected OpenPGP: preference=unprotected
OpenPGP: url=http://example.com/key.txt; id=12345678 OpenPGP: url=http://example.com/key.txt; id=12345678
OpenPGP: id=12345678; url=http://example.com/key.txt; OpenPGP: id=12345678; url=http://example.com/key.txt;
preference=signencrypt preference=signencrypt
OpenPGP: url=http://example.com/key.txt (down 2-3pm UTC); OpenPGP: url=http://example.com/key.txt (down 2-3pm UTC);
id=12345678 (this key is only used at the office); id=12345678 (this key is only used at the office);
preference=sign (unsigned emails are filtered away) preference=sign (unsigned emails are filtered away)
skipping to change at page 7, line 19 skipping to change at page 7, line 19
similar. Should it be in preferred priority order? This draft similar. Should it be in preferred priority order? This draft
tentatively closes this issue by ignoring the matter, until someone tentatively closes this issue by ignoring the matter, until someone
proposes text. proposes text.
The ABNF definition is known to be under-specified. The ABNF definition is known to be under-specified.
7. Acknowledgements 7. Acknowledgements
The content of this document builds on discussions with (in The content of this document builds on discussions with (in
alphabetical order) Christian Biere, Patrick Brunschwig, Jon Callas, alphabetical order) Christian Biere, Patrick Brunschwig, Jon Callas,
Peter J. Holzer, Ingo Klocker, Werner Koch, Jochen Kupper, Charles Dave Evans, Peter J. Holzer, Ingo Klocker, Werner Koch, Jochen
Lindsey, Aleksandar Milivojevic, Xavier Maillard, Greg Sabino Kupper, William Leibzon, Charles Lindsey, Aleksandar Milivojevic,
Mullane, Thomas Roessler, Moritz Schulte, Olav Seyfarth, Thomas Xavier Maillard, Greg Sabino Mullane, Thomas Roessler, Moritz
Sjogren, Paul Walker, and Steve Youngs. No doubt the list is Schulte, Olav Seyfarth, David Shaw, Thomas Sjogren, Paul Walker, and
incomplete. We apologize to anyone we left out. Steve Youngs. No doubt the list is incomplete. We apologize to
anyone we left out.
8. Security Considerations 8. Security Considerations
These headers are intended to be a convenience in locating public The OpenPGP header field is intended to be a convenience in locating
keys: They are neither secure nor intended to be. Since header public keys. They are neither secure nor intended to be. Since the
information is easy to spoof, information contained in headers should message header is easy to spoof, information contained in the header
not be trusted: The information must be verified. How the should not be trusted. The information must be verified.
information is verified is left as an exercise for the reader.
Applications that interpret the data within this header MUST NOT Applications that interpret the field MUST NOT assume that the
assume that the data is correct, and MUST NOT present the data to the content is correct, and MUST NOT present the data to the user in any
user in any way that would cause the user to assume that it is way that would cause the user to assume that it is correct.
correct. Applications that interpret the data within this header Applications that interpret the data within the field SHOULD alert
SHOULD alert the user that this information is not a substitute for the user that this information is not a substitute for personally
personally verifying keys and being a part of the web of trust. verifying keys and being a part of the web of trust.
If an application receives a signed message and uses the information If an application receives a signed message and uses the information
in this header to retrieve a key, the application MAY ignore the 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. 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 This SHOULD be done before the newly retrieved key is imported into
the user's keyring. the user's keyring.
The use of HTTPS [13], DNSSEC [10], SMTP STARTTLS [11], and other The use of HTTPS [12], DNSSEC [15], SMTP STARTTLS [13], IMAP/POP3
secure protocols, may enhance the security of information conveyed STARTTLS [10] and other secure protocols, may enhance the security of
through this header, but does not guarantee any level of security or information conveyed through this field, but does not guarantee any
authenticity. Developers and users must remain aware of this. 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 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 0xDEADBEEF attack"). Verifying the Key ID of a retrived key against
the one provided in this header is thus not sufficient to protect the one provided in the field is thus not sufficient to protect
against a man-in-the-middle attack. Instead, the web-of-trust against a man-in-the-middle attack. Instead, the web-of-trust
mechanism should be used. mechanism should be used.
If an attacker wants to check the validity of Email addresses, he If an attacker wants to check the validity of Email addresses, he
might send out junk email to arbitrary addresses and collect those might send out junk email to arbitrary addresses and collect those
that report back to the crafted OpenPGP URL. To protect against that report back to the crafted OpenPGP URL. To protect against
this, implementations MUST inform the user of that potential privacy this, implementations MUST inform the user of that potential privacy
issue when retrieving keys from an URL provided by the mail headers issue when retrieving keys from an URL provided by the field of an
of an inbound email message: either when the feature is enabled or to inbound email message: either when the feature is enabled or to be
be used for the first time or every time the MUA detects an unknown used for the first time or every time the MUA detects an unknown key.
key.
Given the flexibility of the syntax of the header, slightly varying Given the flexibility of the syntax of the field, slightly varying
the content between messages can be used as a covert channel. the content between messages can be used as a covert channel.
9. IANA Considerations 9. IANA Considerations
The IANA is asked to register the OpenPGP header, using the template The IANA is asked to register the OpenPGP header field, using the
as follows, in accordance with RFC 3864 [15]. template as follows, in accordance with RFC 3864 [14].
Header field name: OpenPGP Header field name: OpenPGP
Applicable protocol: mail, netnews Applicable protocol: mail, netnews
Status: informational Status: informational
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): This document. Specification document(s): This document.
skipping to change at page 9, line 26 skipping to change at page 9, line 26
permission to anyone to use, modify, and distribute it in any way permission to anyone to use, modify, and distribute it in any way
that does not diminish the rights of anyone else to use, modify, that does not diminish the rights of anyone else to use, modify,
and distribute it, provided that redistributed derivative works and distribute it, provided that redistributed derivative works
do not contain misleading author or version information. do not contain misleading author or version information.
Derivative works need not be licensed under similar terms. Derivative works need not be licensed under similar terms.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Horton, M. and R. Adams, "Standard for interchange of USENET [1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
messages", RFC 1036, December 1987.
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996. RFC 2045, November 1996.
[3] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word [2] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
Extensions: Character Sets, Languages, and Continuations", Extensions: Character Sets, Languages, and Continuations",
RFC 2231, November 1997. RFC 2231, November 1997.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax [4] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
Specifications: ABNF", RFC 2234, November 1997.
[6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
August 1998. January 2005.
[7] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP [6] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Message Format", RFC 2440, November 1998. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[8] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
11.2. Informative References 11.2. Informative References
[9] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, [8] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
RFC 959, October 1985. RFC 959, October 1985.
[10] Eastlake, D., "Domain Name System Security Extensions", [9] Horton, M. and R. Adams, "Standard for interchange of USENET
RFC 2535, March 1999. messages", RFC 1036, December 1987.
[11] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, [10] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
June 1999. June 1999.
[12] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[13] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[14] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", [13] Hoffman, P., "SMTP Service Extension for Secure SMTP over
RFC 3548, July 2003. Transport Layer Security", RFC 3207, February 2002.
[15] Klyne, G., Nottingham, M., and J. Mogul, "Registration [14] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[15] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[16] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 4648, October 2006.
Authors' Addresses Authors' Addresses
Atom Smasher Atom Smasher
Email: atom@smasher.org (762A3B98A3C396C9C6B7582AB88D52E4D9F57808) Email: atom@smasher.org (762A3B98A3C396C9C6B7582AB88D52E4D9F57808)
Simon Josefsson Simon Josefsson
Email: simon@josefsson.org (0424D4EE81A0E3D119C6F835EDA21E94B565716F) Email: simon@josefsson.org (0424D4EE81A0E3D119C6F835EDA21E94B565716F)
Intellectual Property Statement 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 12, line 29 skipping to change at page 11, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. 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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 53 change blocks. 
133 lines changed or deleted 142 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/