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: [email protected] (762A3B98A3C396C9C6B7582AB88D52E4D9F57808)		Email: [email protected] (762A3B98A3C396C9C6B7582AB88D52E4D9F57808)
	Simon Josefsson		Simon Josefsson
	Email: [email protected] (0424D4EE81A0E3D119C6F835EDA21E94B565716F)		Email: [email protected] (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
	[email protected].		[email protected].
	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/