draft-josefsson-openpgp-mailnews-header-03.txt   draft-josefsson-openpgp-mailnews-header-04.txt 
Network Working Group A. Smasher Network Working Group A. Smasher
Internet-Draft S. Josefsson Internet-Draft S. Josefsson
Intended status: Informational February 23, 2008 Intended status: Informational April 2, 2008
Expires: August 26, 2008 Expires: October 4, 2008
The OpenPGP mail and news header field The OpenPGP mail and news header field
draft-josefsson-openpgp-mailnews-header-03 draft-josefsson-openpgp-mailnews-header-04
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 34 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 August 26, 2008. This Internet-Draft will expire on October 4, 2008.
Copyright Notice
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
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. Key URL field: url . . . . . . . . . . . . . . . . . . . . 5 3.2. Key URL field: url . . . . . . . . . . . . . . . . . . . . 5
3.3. Protection Preference Field: preference . . . . . . . . . 6 3.3. Protection Preference Field: preference . . . . . . . . . 6
4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 9
10. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11 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
field. This field should be considered "informational" (and field. This field should be considered "informational" (and
"optional"), and be suitable for both mail [4] and netnews [9] "optional"), and be suitable for both mail [RFC2822] and netnews
messages. This field should be used to provide information about the [RFC1036] messages. This field should be used to provide information
sender's OpenPGP [6] key. This field MAY be used in any message. 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. 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 [3]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Background and Motivation 2. Background and Motivation
There are quite a few PGP and GnuPG users who add header fields with 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 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 fields are not standardized, so they "X-PGP-Fingerprint:". The fields are not standardized, so they
cannot be reliably parsed automatically by applications, only parsed cannot be reliably parsed automatically by applications, only parsed
by humans. by humans.
skipping to change at page 4, line 25 skipping to change at page 4, line 27
Because the header is typically not integrity protected, the Because the header is typically not integrity protected, the
information conveyed in the OpenPGP header field MUST NOT be trusted information conveyed in the OpenPGP header field MUST NOT be trusted
without additional verification. Some of the information given in without additional verification. Some of the information given in
this field may also be given on the OpenPGP key itself. When these this field may also be given on the OpenPGP key itself. When these
two sources conflict, users SHOULD favor the information from the two sources conflict, users SHOULD favor the information from the
OpenPGP key, as that information can be cryptographically protected. OpenPGP key, as that information can be cryptographically protected.
The field is of a "structured" type (see section 2.2.2 of RFC 2822). 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 In general, the structure consist of one or more parameters, each
consisting of one attribute and one value. The terminology and consisting of one attribute and one value. The terminology and
format of the field was inspired by MIME [1]. The various provisions format of the field was inspired by MIME [RFC2045]. The various
of RFC 2045 apply. In particular, the value part of all parameters provisions of RFC 2045 apply. In particular, the value part of
may be quoted; whitespace, foldoing and comments may occur in the parameters may be quoted; whitespace, folding and comments may occur
middle of parameters. The provisions of MIME [2] also apply; in in the middle of parameters. The provisions of MIME [RFC2231] also
particular it deals with handling parameters of excessive length. apply; in particular it deals with handling parameters of excessive
length.
In the Augmented BNF [7] notation, the OpenPGP header field is The OpenPGP header field is defined as below in the Augmented BNF
defined as below. By itself, however, this grammar is incomplete. [RFC5234] notation. By itself, however, this grammar is incomplete.
It refers by name to several syntax rules that are defined by RFC It refers by name to syntax rules that are defined in [RFC2822] and
2822 and the URI syntax document [5]. Rather than reproduce those [RFC3986]. Rather than reproduce those definitions here, and risk
definitions here, and risk unintentional differences between the two, unintentional differences between the two, this document refer the
this document refer the reader to RFC 2822 and RFC 3986 for the reader to the other documents for the definition of non-terminals.
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. The field SHOULD NOT appear more than allow for future extensions. A given parameter type (i.e., "id",
once within a message. A given parameter type (i.e., "id", "url" or "url" or "preference") MUST NOT occur more than once. The OpenPGP:
"preference") MUST NOT occur more than once. field itself SHOULD NOT appear more than once within a message.
openpgp := "OpenPGP:"
(openpgp-parameter *(";" openpgp-parameter))
CRLF
id := 8*HEXDIG
url := absoluteURI ; Defined in RFC 3986. openpgp = "OpenPGP:" SP *CFWS openpgp-params *CFWS CRLF
; CFWS is defined in RFC 2822.
preference := "sign" / "encrypt" / "signencrypt" / "unprotected" openpgp-params
= (openpgp-parameter *(";" *CFWS openpgp-parameter))
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.
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 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 hex [16] notation. 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 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 [11] or FTP [8]. The URL MUST be fully family, such as HTTP [RFC2616] or FTP [RFC0959]. The URL MUST be
qualified, MUST explicitly specify a protocol and SHOULD be fully 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
quality of protection preferred by the sender. The available choices quality of protection preferred by the sender. The available choices
skipping to change at page 7, line 5 skipping to change at page 7, line 5
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)
6. Open Issues 6. Acknowledgements
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.
The ABNF definition is known to be under-specified.
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,
Dave Evans, Peter J. Holzer, Ingo Klocker, Werner Koch, Jochen Dave Evans, Peter J. Holzer, Ingo Klocker, Werner Koch, Jochen
Kupper, William Leibzon, Charles Lindsey, Aleksandar Milivojevic, Kupper, William Leibzon, Charles Lindsey, Aleksandar Milivojevic,
Xavier Maillard, Greg Sabino Mullane, Thomas Roessler, Moritz Xavier Maillard, Greg Sabino Mullane, Thomas Roessler, Moritz
Schulte, Olav Seyfarth, David Shaw, Thomas Sjogren, Paul Walker, and Schulte, Olav Seyfarth, David Shaw, Thomas Sjogren, Paul Walker, and
Steve Youngs. No doubt the list is incomplete. We apologize to Steve Youngs. No doubt the list is incomplete. We apologize to
anyone we left out. anyone we left out.
8. Security Considerations 7. Security Considerations
The OpenPGP header field is intended to be a convenience in locating The OpenPGP header field is intended to be a convenience in locating
public keys. They are neither secure nor intended to be. Since the public keys. They are neither secure nor intended to be. Since the
message header is easy to spoof, information contained in the header message header is easy to spoof, information contained in the header
should not be trusted. The information must be verified. should not be trusted. The information must be verified.
Applications that interpret the field MUST NOT assume that the Applications that interpret the field MUST NOT assume that the
content is correct, and MUST NOT present the data to the user in any 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. way that would cause the user to assume that it is correct.
Applications that interpret the data within the field SHOULD alert Applications that interpret the data within the field SHOULD alert
the user that this information is not a substitute for personally the user that this information is not a substitute for 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 the field 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 [12], DNSSEC [15], SMTP STARTTLS [13], IMAP/POP3 The use of HTTPS [RFC2818], DNSSEC [RFC4033], SMTP STARTTLS
STARTTLS [10] and other secure protocols, may enhance the security of [RFC3207], IMAP/POP3 STARTTLS [RFC2595] and other secure protocols,
information conveyed through this field, but does not guarantee any may enhance the security of information conveyed through this field,
level of security or authenticity. Developers and users must remain but does not guarantee any level of security or authenticity.
aware of this. 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 retrieved key against
the one provided in the field 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 field of an 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 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. 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 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 8. IANA Considerations
The IANA is asked to register the OpenPGP header field, using the The IANA is asked to register the OpenPGP header field, using the
template as follows, in accordance with RFC 3864 [14]. template as follows, in accordance with RFC 3864 [RFC3864].
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.
Related information: None Related information: None
10. Copying conditions 9. Copying conditions
In addition to the IETF/ISOC copying conditions, the following
statement grant third parties further rights to this document.
Copyright (C) 2004 Atom Smasher
Copyright (C) 2004, 2005 Simon Josefsson
Regarding this entire document or any portion of it, the authors Regarding this entire document or any portion of it, the authors
makes no guarantees and is not responsible for any damage makes no guarantees and is not responsible for any damage resulting
resulting from its use. The authors grants irrevocable from its use. The authors grants irrevocable permission to anyone to
permission to anyone to use, modify, and distribute it in any way use, modify, and distribute it in any way that does not diminish the
that does not diminish the rights of anyone else to use, modify, rights of anyone else to use, modify, and distribute it, provided
and distribute it, provided that redistributed derivative works that redistributed derivative works do not contain misleading author
do not contain misleading author or version information. or version information. Derivative works need not be licensed under
Derivative works need not be licensed under similar terms. similar terms.
11. References 10. References
11.1. Normative References 10.1. Normative References
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] 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
RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[2] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Extensions: Character Sets, Languages, and Continuations", Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2231, November 1997.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Levels", BCP 14, RFC 2119, March 1997. Word Extensions:
Character Sets, Languages, and Continuations", RFC 2231,
November 1997.
[4] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, Resource Identifier (URI): Generic Syntax", STD 66,
January 2005. RFC 3986, January 2005.
[6] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
11.2. Informative References 10.2. Informative References
[8] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
RFC 959, October 1985. STD 9, RFC 959, October 1985.
[9] Horton, M. and R. Adams, "Standard for interchange of USENET [RFC1036] Horton, M. and R. Adams, "Standard for interchange of
messages", RFC 1036, December 1987. USENET messages", RFC 1036, December 1987.
[10] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
June 1999. RFC 2595, June 1999.
[11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[13] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002. Transport Layer Security", RFC 3207, February 2002.
[14] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] 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, [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
"DNS Security Introduction and Requirements", RFC 4033, Rose, "DNS Security Introduction and Requirements",
March 2005. RFC 4033, March 2005.
[16] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
RFC 4648, October 2006. 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)
skipping to change at page 11, line 44 skipping to change at line 434
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 43 change blocks. 
115 lines changed or deleted 99 lines changed or added

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