draft-josefsson-openpgp-mailnews-header-04.txt		draft-josefsson-openpgp-mailnews-header-05.txt
	Network Working Group A. Smasher		Network Working Group A. Smasher
	Internet-Draft S. Josefsson		Internet-Draft S. Josefsson
	Intended status: Informational April 2, 2008		Intended status: Informational April 15, 2008
	Expires: October 4, 2008		Expires: October 17, 2008
	The OpenPGP mail and news header field		The OpenPGP mail and news header field
	draft-josefsson-openpgp-mailnews-header-04		draft-josefsson-openpgp-mailnews-header-05
	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 October 4, 2008.		This Internet-Draft will expire on October 17, 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 . . . . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	9. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 9		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . . 9		Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	Intellectual Property and Copyright Statements . . . . . . . . . . 11		Intellectual Property and Copyright Statements . . . . . . . . . . 12
	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 [RFC2822] and netnews		"optional"), and be suitable for both mail [RFC2822] and netnews
	[RFC1036] messages. This field should be used to provide information		[RFC1036] messages. This field should be used to provide information
	about the sender's OpenPGP [RFC4880] key. This field MAY be used in		about the sender's OpenPGP [RFC4880] key. This field MAY be used in
	any message.		any message.
	skipping to change at page 3, line 37		skipping to change at page 3, line 37
	cannot be reliably parsed automatically by applications, only parsed		cannot be reliably parsed automatically by applications, only 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 field 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 field specified here is named "OpenPGP".		both share. The field specified here is named "OpenPGP".
	The OpenPGP field is not a required part of successful use of OpenPGP		The OpenPGP field is not a required part of successful use of OpenPGP
	in e-mail. It is intended as a convenience, in those situations		in e-mail or other messages. It is intended as a convenience, in
	where the user experience may be enhanced by using the information in		those situations where the user experience may be enhanced by using
	the field. Consequently, the information in the field should not		the information in the field. Consequently, the information in the
	disrupt the normal OpenPGP key retrieval and web of trust mechanism.		field should not disrupt the normal OpenPGP key retrieval and web of
	Neither the integrity nor the authenticity of the information in the		trust mechanism. Neither the integrity nor the authenticity of the
	field should be assumed to be correct or be trust-worthy.		information in the field should be assumed to be correct or trust-
			worthy.
	No specific scenario when the field should be used, nor how it should		No specific scenario when the field should be used, nor how it should
	be used in that scenario, are suggested by this document. It is		be used in that scenario, are suggested by this document. It is
	acknowledged that the dominant use of the information in the field		acknowledged that the dominant use of the information in the field
	may be by humans and not applications.		may be by humans and not applications.
	To promote good use of the field, 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 field.		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 fields if an error condition occur. Since		presence of the OpenPGP fields if it would cause an error condition.
	the field is optional, this approach should not be difficult to		Since 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
	The OpenPGP header field is intended to present characteristics of		The OpenPGP header field is intended to present characteristics of
	the sender's OpenPGP key. The field may contain the Key ID and the		the sender's OpenPGP key. The field typically contains the Key ID
	URL where the key can be retrieved.		and the URL where the key can be retrieved.
	Because the header is typically not integrity protected, the		Because the mail 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 in 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 [RFC2045]. The various		format of the field was inspired by MIME [RFC2045]. The various
	provisions of RFC 2045 apply. In particular, the value part of		provisions of RFC 2045 apply. In particular, the value part of
	parameters may be quoted; whitespace, folding and comments may occur		parameters may be quoted; whitespace, folding and comments may occur
	in the middle of parameters. The provisions of MIME [RFC2231] also		in the middle of parameters; except as noted below. The provisions
	apply; in particular it deals with handling parameters of excessive		of MIME [RFC2231] also apply; in particular it deals with handling
	length.		parameters of excessive length.
	The OpenPGP header field is defined as below in the Augmented BNF		The OpenPGP header field is defined as below in the Augmented BNF
	[RFC5234] notation. By itself, however, this grammar is incomplete.		[RFC5234] notation. By itself, however, this grammar is incomplete.
	It refers by name to syntax rules that are defined in [RFC2822] and		It refers by name to syntax rules that are defined in [RFC2822] and
	[RFC3986]. Rather than reproduce those definitions here, and risk		[RFC3986]. Rather than reproduce those definitions here, and risk
	unintentional differences between the two, this document refer the		unintentional differences between the two, this document refer the
	reader to the other documents for the definition of non-terminals.		reader to the other documents for the definition of non-terminals.
	Unrecognized parameters MUST be ignored. The grammar permit them to		Implementations MUST understand the "id", "url", and "preference"
	allow for future extensions. A given parameter type (i.e., "id",		attributes. Parameter with unrecognized attributes MUST be ignored.
	"url" or "preference") MUST NOT occur more than once. The OpenPGP:		The grammar permit unknown parameters to allow for future extensions.
	field itself SHOULD NOT appear more than once within a message.		Each parameter attribute (e.g., "url") MUST NOT occur more than once
			in any single instance of the OpenPGP field. The OpenPGP field
			itself MAY occur more than once in a single email (for example if the
			sender has multiple keys).
	openpgp = "OpenPGP:" SP *CFWS openpgp-params *CFWS CRLF		openpgp = "OpenPGP:" SP *CFWS o-params CRLF
	; CFWS is defined in RFC 2822.		; CFWS is defined in RFC 2822.
			; SP and CRLF are defined in RFC 5234.
	openpgp-params		o-params = (o-parameter *CFWS *(";" *CFWS o-params))
	= (openpgp-parameter *(";" *CFWS openpgp-parameter))
	openpgp-parameter		o-parameter =
	= ("id" "=" id) /		("id" "=" id) /
	("url" "=" url) /		("url" "=" url) /
	("preference" "=" preference) /		("preference" "=" preference) /
	parameter ; See RFC 2045 for definition of parameter.		parameter ; normally unused, for extensions
			; parameter is defined in RFC 2045.
	id = 8*HEXDIG ; Defined in RFC 5234.		id = 8*HEXDIG
			; HEXDIG is defined in RFC 5234.
			; Matching of value is case-insensitive.
	url = absoluteURI ; Defined in RFC 3986.		url = absoluteURI / quoted-url
			; absoluteURI is defined in RFC 3986.
			; If URL contains the character ';',
			; the quoted-url form MUST be used.
			quoted-url = DQUOTE absoluteURI DQUOTE
			; DQUOTE is defined in RFC 5234.
	preference = "sign" / "encrypt" / "signencrypt" / "unprotected"		preference = "sign" / "encrypt" / "signencrypt" / "unprotected"
			; Matching of values are case-insensitive.
	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" parameter, if present, MUST hold the Key ID or key
	key ID. The value MUST identify the key ID (in either short or long		fingerprint for the primary key. The value uses the hex [RFC4648]
	form) or the fingerprint, all using the hex [RFC4648] notation.		notation. The parameter value is case-insensitive.
	The length of the field imply the kind of key id, i.e., short or long		The length of the field determine whether it denotes a Key ID (8 hex
	form, or a v3 or v4 key.		symbols), a long Key ID (16 hex symbols), a v3 key fingerprint (32
			hex symbols), or a v4 key fingerprint (40 hex symbols).
	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=1234567890abcdef0123456789ABCDEF01234567 (v4 fingerprint)
	id=1234567890ABCDEF01234567890ABCDE (v3 fingerprint, deprecated)		id=1234567890ABCDEF0123456789ABCDEF (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" parameter, if present, MUST specify a URL where the public
	the public key can be found. It is RECOMMENDED to use a common URL		key can be found. It is RECOMMENDED to use a common URL family, such
	family, such as HTTP [RFC2616] or FTP [RFC0959]. The URL MUST be		as HTTP [RFC2616] or FTP [RFC0959]. The URL MUST be fully qualified,
	fully qualified, MUST explicitly specify a protocol and SHOULD be		MUST explicitly specify a protocol and SHOULD be accessible on the
	accessible on the public Internet.		public Internet.
			The content of where the URL points SHOULD be either an ASCII armored
			or binary OpenPGP packet containing the key. A valid reason for
			storing something else may be if the key has been revoked.
	For example:		For example:
	url=http://example.org/pgp.txt		url=http://example.org/pgp.txt
			url="http://example.org/funny;name.txt"
			If the URL contains the character ';' the entire URL MUST be quoted,
			as illustrated in the example.
	3.3. Protection Preference Field: preference		3.3. Protection Preference Field: preference
	The "preference" attribute=value pair, if present, specify the		The "preference" parameter, if present, specify the quality of
	quality of protection preferred by the sender. The available choices		protection preferred by the sender. The parameter value is case-
	are "unprotected" which means that the sender prefer not to receive		insensitive.
	OpenPGP protected e-mails. A "sign" token means that the sender
	prefer to receive digitally signed e-mails. A "encrypt" token means		The available values are as follows. A "unprotected" token means
	that the sender prefer to receive digitally encrypted e-mails. A		that the sender prefer not to receive OpenPGP protected e-mails. A
	"signencrypt" token means that the sender prefer to receive digitally		"sign" token means that the sender prefer to receive digitally signed
	encrypted and signed e-mails. Note that there is no technical		e-mails. A "encrypt" token means that the sender prefer to receive
	requirement on the receiver to follow the stated preference.		encrypted e-mails. A "signencrypt" token means that the sender
			prefer to receive encrypted and signed e-mails.
			Note that there is no normative requirement on the receiver to follow
			the stated preference.
	For example:		For example:
	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 OpenPGP fields 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 how the field may be used. This list is		These are valid examples of how the field may be used. This list is
	not meant to be exhaustive, but do reflect expected typical usages.		not meant to be exhaustive, but to reflect expected 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)
			OpenPGP: id=12345678; url="http://example.com/openpgp;key.txt"
	6. Acknowledgements		6. 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, Tim Polk, Thomas Roessler,
	Schulte, Olav Seyfarth, David Shaw, Thomas Sjogren, Paul Walker, and		Moritz Schulte, Olav Seyfarth, David Shaw, Thomas Sjogren, Paul
	Steve Youngs. No doubt the list is incomplete. We apologize to		Walker, and Steve Youngs. No doubt the list is incomplete. We
	anyone we left out.		apologize to anyone we left out.
	7. 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. The OpenPGP header is neither secure nor intended to
	message header is easy to spoof, information contained in the header		be. Since the message header is easy to spoof, information contained
	should not be trusted. The information must be verified.		in the header 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 automatically retrieve a key, the application MAY
	retrieved key if it is not the same key used to sign the message.		ignore the retrieved key if it is not the same key used to sign the
	This SHOULD be done before the newly retrieved key is imported into		message. This SHOULD be done before the newly retrieved key is
	the user's keyring.		imported into the user's keyring.
	The use of HTTPS [RFC2818], DNSSEC [RFC4033], SMTP STARTTLS		The use of HTTPS [RFC2818], DNSSEC [RFC4033], SMTP STARTTLS
	[RFC3207], IMAP/POP3 STARTTLS [RFC2595] and other secure protocols,		[RFC3207], IMAP/POP3 STARTTLS [RFC2595] and other secure protocols,
	may enhance the security of information conveyed through this field,		may enhance the security of information conveyed through this field,
	but does not guarantee any level of security or authenticity.		but does not guarantee any level of security or authenticity.
	Developers and users must remain 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 retrieved 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 email arbitrary addresses with a unique OpenPGP header field
	that report back to the crafted OpenPGP URL. To protect against		URL (presumably an URL under the attacker's control). The attacker
			can verify the liveness of each email address by checking if the URL
			for each particular recipient has been retrieved. 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. This
			is already possible using other header fields in email, and thus the
			OpenPGP field do not introduce a new vulnerability here.
	8. 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 [RFC3864].		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
	skipping to change at page 8, line 21		skipping to change at page 9, line 4
	8. 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 [RFC3864].		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
	9. Copying conditions		9. References
	Regarding this entire document or any portion of it, the authors
	makes no guarantees and is not responsible for any damage 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
	10.1. Normative References		9.1. Normative References
	[RFC2045] 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		Extensions (MIME) Part One: Format of Internet Message
	Bodies", RFC 2045, November 1996.		Bodies", RFC 2045, November 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded		[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
	Word Extensions:		Word Extensions:
	skipping to change at page 9, line 45		skipping to change at page 10, line 34
	[RFC3986] 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,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, January 2005.		RFC 3986, January 2005.
	[RFC4880] 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.
	[RFC5234] 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.
	10.2. Informative References		9.2. Informative References
	[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",		[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
	STD 9, RFC 959, October 1985.		STD 9, RFC 959, October 1985.
	[RFC1036] Horton, M. and R. Adams, "Standard for interchange of		[RFC1036] Horton, M. and R. Adams, "Standard for interchange of
	USENET messages", RFC 1036, December 1987.		USENET messages", RFC 1036, December 1987.
	[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",		[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
	RFC 2595, June 1999.		RFC 2595, June 1999.
	skipping to change at page 10, line 28		skipping to change at page 11, line 16
	Procedures for Message Header Fields", BCP 90, RFC 3864,		Procedures for Message Header Fields", BCP 90, RFC 3864,
	September 2004.		September 2004.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements",		Rose, "DNS Security Introduction and Requirements",
	RFC 4033, March 2005.		RFC 4033, March 2005.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, October 2006.		Encodings", RFC 4648, October 2006.
			Appendix A. Copying conditions
			Regarding this entire document or any portion of it, the authors
			makes no guarantees and is not responsible for any damage 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.
	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)
End of changes. 41 change blocks.
	93 lines changed or deleted		124 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/