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