draft-josefsson-openpgp-mailnews-header-00.txt   draft-josefsson-openpgp-mailnews-header-01.txt 
Network Working Group A. Smasher Network Working Group A. Smasher
Internet-Draft S. Josefsson Internet-Draft S. Josefsson
Expires: July 8, 2005 January 7, 2005 Expires: November 26, 2005 May 25, 2005
The OpenPGP mail and news header The OpenPGP mail and news header
draft-josefsson-openpgp-mailnews-header-00 draft-josefsson-openpgp-mailnews-header-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 July 8, 2005. This Internet-Draft will expire on November 26, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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
1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background and Motivation . . . . . . . . . . . . . . . . . . 3 2. Background and Motivation . . . . . . . . . . . . . . . . . 3
3. OpenPGP Header Field . . . . . . . . . . . . . . . . . . . . . 4 3. OpenPGP Header Field . . . . . . . . . . . . . . . . . . . . 4
3.1 Primary Key ID field: id . . . . . . . . . . . . . . . . . 5 3.1 Primary Key ID field: id . . . . . . . . . . . . . . . . . 5
3.2 Primary Key Algorithm field: algo . . . . . . . . . . . . 5 3.2 Key URL field: url . . . . . . . . . . . . . . . . . . . . 5
3.3 Primary Key Size field: size . . . . . . . . . . . . . . . 5 4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Key URL field: url . . . . . . . . . . . . . . . . . . . . 6 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5 Key Creation Date field: created . . . . . . . . . . . . . 6 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . 6
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 10. Copying conditions . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 8 11.1 Normative References . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.2 Informative References . . . . . . . . . . . . . . . . . 9
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
10.2 Informative References . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
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"), This header should be considered "informational" (and "optional"),
and be suitable for both mail [6] and netnews [1] messages. This and be suitable for both mail [8] and netnews [1] messages. This
header should be used to provide information about the sender's header should be used to provide information about the sender's
OpenPGP [5] key. This header MAY be used in any message. OpenPGP [7] key. This header 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 [2]. document are to be interpreted as described in RFC 2119 [4].
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 headers with
information about the sender's OpenPGP key. Headers in current use information about the sender's OpenPGP key. Headers 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 headers lack standardization, which
prevent them from being reliably parsed automatically by prevent them from being reliably parsed automatically by
applications, rather than manually parsed by humans. applications, rather than manually parsed by humans.
skipping to change at page 4, line 11 skipping to change at page 4, line 11
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 header.
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 header if an error condition occur. Since
the header is optional, this approach should not be difficult to the header 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, if used, is intended to present characteristics of the This header is intended to present characteristics of the sender's
sender's OpenPGP key, such as the primary key ID (or fingerprint), OpenPGP key. It may contain the Key ID and the URL where the key can
algorithm, size and URL where the key can be found. This header is be retrieved.
of a "structured" type (see section 2.2.2 of RFC 2822). In general,
the structure consist of one or more attribute and value pairs. The
terminology and format of the header was inspired by MIME [8].
This header SHOULD NOT appear more than once within a message. This header 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 header was inspired by MIME [2]. 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 MIME [3] also apply;
in particular it deals with handling parameters of excessive length.
In the Augmented BNF [3] notation, an OpenPGP header field is defined In the Augmented BNF [5] notation, an OpenPGP header field is defined
as below. By itself, however, this grammar is incomplete. It refers 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 by name to several syntax rules that are defined by RFC 2822 and the
URI syntax document [4]. Rather than reproduce those definitions URI syntax document [6]. Rather than reproduce those definitions
here, and risk unintentional differences between the two, this here, and risk unintentional differences between the two, this
document refer the reader to RFC 2822 and RFC 2396 for the definition document refer the reader to RFC 2822 and RFC 2396 for the definition
of non-terminals. of non-terminals.
openpgp := "OpenPGP:" id-or-url / (parameter *(";" parameter)) Unrecognized parameters MUST be ignored. The grammar permit them to
allow for future extensions. This header SHOULD NOT appear more than
once within a message. A given parameter type (i.e., "id" or "url")
may appear no more than once.
openpgp := "OpenPGP:" id-or-url /
(openpgp-parameter *(";" openpgp-parameter))
CRLF CRLF
id-or-url := id / url id-or-url := id / url
id := ["0x"] (4*HEXDIG / 8*HEXDIG / 32*HEXDIG / 40*HEXDIG) id := *HEXDIG
url := absoluteURI ; Defined in RFC 2396. url := absoluteURI ; Defined in RFC 2396.
algo := *DIGIT ; Value in RFC 2440 section 9.1. openpgp-parameter
:= ("id" "=" id) /
size := *DIGIT ; Primary key size in bits.
created := *DIGIT ; Correspond to four-octet number in
; RFC 2440 V3/V4 key packet that indicate
; the time the key was created, expressed as
; an unsigned decimal integer.
parameter := ("id" "=" id) /
("url" "=" url) / ("url" "=" url) /
("algo" "=" algo) / parameter ; See RFC 2045 for definition of parameter.
("size" "=" size) /
("created" "=" created)
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 MAY be prefixed with "0x". The value MUST key ID. The value MUST identify the key ID (in either short or long
identify the key ID (in either short or long form) or the form) or the fingerprint, all using the hexadecimal [14] notation.
fingerprint, all using the hexadecimal [13] notation.
A short key ID is a 32 bit key ID, represented as 8 characters.
A long key ID is a 64 bit key ID, represented as 16 characters.
A v4 fingerprint is a 160 bit key ID, represented as 40 characters.
A v3 fingerprint is a 128 bit key ID, represented as 32 characters.
Note that each of the following examples includes a comment, which is
optional.
id=12345678 (short key ID, no 0x prefix)
id=0x12345678 (short key ID)
id=0x1234567890ABCDEF (long key ID)
id=0x1234567890ABCDEF01234567890ABCDEF0123456 (v4 fingerprint)
id=0x1234567890ABCDEF01234567890ABCDE (v3 fingerprint)
3.2 Primary Key Algorithm field: algo
The "algo" attribute=value pair, if present, MUST specify the The length of the field imply the kind of key id, i.e., short or long
algorithm of the primary key. The algorithm of the primary key MUST form, or a v3 or v4 key.
be presented as the value defined in section 9.1 of RFC 2440 (Public
Key Algorithms). The value MUST be presented as an integer in
decimal notation.
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.
algo=1 (RSA) id=12345678 (short key ID)
algo=17 (DSA) id=1234567890ABCDEF (long key ID)
id=1234567890ABCDEF01234567890ABCDEF0123456 (v4 fingerprint)
3.3 Primary Key Size field: size id=1234567890ABCDEF01234567890ABCDE (v3 fingerprint, deprecated)
The "size" attribute=value pair, if present, MUST specify the size of
the primary key. The size of the primary key MUST be presented as
the number of bits in the key's modulus. The value MUST be presented
as an integer in decimal notation.
Note that one of the following examples includes a comment, which is
optional.
size=1024
size=2048 (bits)
3.4 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 [11] or FTP [7]. The URL MUST be fully family, such as HTTP [12] or FTP [9]. 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.5 Key Creation Date field: created
This "created" attribute=value pair, if present, MUST define the
creation date of the primary key. The creation date of the primary
key MUST be presented as specified in section 5.5.2 of RFC2440
(Public Key Packet Formats). The value MUST be presented as a
integer in decimal notation.
Note that the following example includes a comment, which is
optional.
created=1104629466 (Sun Jan 2 01:31:06 UTC 2005)
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 header field bodies with comments:
id=0xB565716F (key stored on non-networked laptop) id=B565716F (key stored on non-networked laptop)
id=0x12345678; algo=1 (RSA Encrypt or Sign) id=12345678 (1024 bit RSA Key for Encrypt or Sign)
id=0xABCD0123; created=1104629115 (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 ways in which this header may be used.
This list of examples is not meant to be exhaustive. This list is not meant to be exhaustive, but do reflect expected
typical usages.
OpenPGP: id=0x12345678 OpenPGP: 12345678
OpenPGP: id=0x12345678; algo=1 (RSA); size=2048 OpenPGP: id=12345678
OpenPGP: http://example.com/key.txt
OpenPGP: url=http://example.com/key.txt OpenPGP: url=http://example.com/key.txt
OpenPGP: url=http://example.com/key.txt; OpenPGP: url=http://example.com/key.txt; id=12345678
id=0x12345678 (this key is only used at the office) OpenPGP: id=12345678; url=http://example.com/key.txt
OpenPGP: url=http://example.com/key.txt (down 2-3pm UTC);
id=12345678 (this key is only used at the office)
6. Open Issues 6. Open Issues
Should the algo/size/created fields be included? They are supposedly
only there for v3 keys.
Should there be a "supports" field, that signal whether the sender Should there be a "supports" field, that signal whether the sender
support inline PGP or PGP/MIME? As in supports="inline, mime" or support inline PGP or PGP/MIME? As in supports="inline, mime" or
similar. Should it be in preferred priority order? similar. Should it be in preferred priority order?
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, Peter J. alphabetical order) Christian Biere, Patrick Brunschwig, Jon Callas,
Holzer, Ingo Klocker, Werner Koch, Jochen Kupper, Aleksandar Peter J. Holzer, Ingo Klocker, Werner Koch, Jochen Kupper, Charles
Milivojevic, Xavier Maillard, Greg Sabino Mullane, Thomas Roessler, Lindsey, Aleksandar Milivojevic, Xavier Maillard, Greg Sabino
Moritz Schulte, Thomas Sjogren, Paul Walker, and Steve Youngs. No Mullane, Thomas Roessler, Moritz Schulte, Olav Seyfarth, Thomas
doubt the list is incomplete. We apologize to anyone we left out. Sjogren, Paul Walker, and 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 These headers are intended to be a convenience in locating public
keys: They are neither secure nor intended to be. Since header keys: They are neither secure nor intended to be. Since header
information is easy to spoof, information contained in headers should information is easy to spoof, information contained in headers should
not be trusted: The information must be verified. How the not be trusted: The information must be verified. How the
information is verified is left as an exercise for the reader. 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 data within this header MUST NOT
skipping to change at page 8, line 8 skipping to change at page 7, line 8
SHOULD alert the user that this information is not a substitute for SHOULD alert the user that this information is not a substitute for
personally verifying keys and being a part of the web of trust. personally 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 this header 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 [12], DNSSEC [9], SMTP STARTTLS [10], and other The use of HTTPS [13], DNSSEC [10], SMTP STARTTLS [11], and other
secure protocols, may enhance the security of information conveyed secure protocols, may enhance the security of information conveyed
through this header, but does not guarantee any level of security or through this header, but does not guarantee any level of security or
authenticity. Developers and users must remain aware of this. 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 retrived key against
the one provided in this header 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
issue when retrieving keys from an URL provided by the mail headers
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 header, slightly varying Given the flexibility of the syntax of the header, 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. Copying conditions 9. IANA Considerations
The IANA is asked to register the OpenPGP header, using the template
as follows, in accordance with RFC 3864 [15].
Header field name: OpenPGP
Applicable protocol: mail, netnews
Status: informational
Author/Change controller: IETF
Specification document(s): This document.
Related information: None
10. Copying conditions
In addition to the IETF/ISOC copying conditions, the following In addition to the IETF/ISOC copying conditions, the following
statement grant third parties further rights to this document. statement grant third parties further rights to this document.
Copyright (C) 2004 Atom Smasher Copyright (C) 2004 Atom Smasher
Copyright (C) 2004, 2005 Simon Josefsson Copyright (C) 2004, 2005 Simon Josefsson
Copying and distribution of the work, with or without Regarding this entire document or any portion of it, the authors
modification, are permitted in any medium without royalty makes no guarantees and is not responsible for any damage
provided the copyright notice and this notice are preserved. 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 11. References
10.1 Normative References 11.1 Normative References
[1] Horton, M. and R. Adams, "Standard for interchange of USENET [1] Horton, M. and R. Adams, "Standard for interchange of USENET
messages", RFC 1036, December 1987. messages", RFC 1036, December 1987.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[3] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
Extensions: Character Sets, Languages, and Continuations",
RFC 2231, November 1997.
[4] 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.
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource [6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[5] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP [7] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP
Message Format", RFC 2440, November 1998. Message Format", RFC 2440, November 1998.
[6] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [8] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
10.2 Informative References 11.2 Informative References
[7] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, [9] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
RFC 959, October 1985. RFC 959, October 1985.
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [10] Eastlake, D., "Domain Name System Security Extensions",
Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2535, March 1999.
RFC 2045, November 1996.
[9] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[10] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, [11] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
June 1999. June 1999.
[11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [12] 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.
[12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [13] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[13] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", [14] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003. RFC 3548, July 2003.
[15] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
Authors' Addresses Authors' Addresses
Atom Smasher Atom Smasher
EMail: atom@smasher.org (0x762A3B98A3C396C9C6B7582AB88D52E4D9F57808) Email: atom@smasher.org (0x762A3B98A3C396C9C6B7582AB88D52E4D9F57808)
Simon Josefsson Simon Josefsson
EMail: simon@josefsson.org (0x0424D4EE81A0E3D119C6F835EDA21E94B565716F) Email: simon@josefsson.org (0x0424D4EE81A0E3D119C6F835EDA21E94B565716F)
Intellectual Property Statement Intellectual Property Statement
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
 End of changes. 

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