draft-josefsson-openpgp-mailnews-header-05.txt		draft-josefsson-openpgp-mailnews-header-06.txt
	Network Working Group A. Smasher		Network Working Group A. Smasher
	Internet-Draft S. Josefsson		Internet-Draft S. Josefsson
	Intended status: Informational April 15, 2008		Intended status: Informational May 20, 2008
	Expires: October 17, 2008		Expires: November 21, 2008
	The OpenPGP mail and news header field		The "OpenPGP" mail and news header field
	draft-josefsson-openpgp-mailnews-header-05		draft-josefsson-openpgp-mailnews-header-06
	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 17, 2008.		This Internet-Draft will expire on November 21, 2008.
	Abstract		Abstract
	This document describes the OpenPGP mail and news header field. The		This document describes the "OpenPGP" mail and news header field.
	field provide information about the sender's OpenPGP key.		The 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 . . . . . . . . . . . . . . . . . . . . 6		3.2. Key URL field: url . . . . . . . . . . . . . . . . . . . . 6
	skipping to change at page 3, line 30		skipping to change at page 3, line 30
	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.
	Since both PGP and GnuPG rely on the OpenPGP protocol, it appear		Since both PGP and GnuPG rely on the OpenPGP protocol, it appears
	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 or other messages. It is intended as a convenience, in		in e-mail or other messages. It is intended as a convenience, in
	those situations where the user experience may be enhanced by using		those situations where the user experience may be enhanced by using
	the information in the field. Consequently, the information in the		the information in the field. Consequently, the information in the
	field should not disrupt the normal OpenPGP key retrieval and web of		field should not disrupt the normal OpenPGP key retrieval and web of
	trust mechanism. Neither the integrity nor the authenticity of the		trust mechanism. Neither the integrity nor the authenticity of the
	information in the field should be assumed to be correct or trust-		information in the field should be assumed to be correct or trust-
	worthy.		worthy.
	No specific scenario when the field should be used, nor how it should		This document neither suggests a specific scenario of when the field
	be used in that scenario, are suggested by this document. It is		should be used, nor how it should be used. It is acknowledged that
	acknowledged that the dominant use of the information in the field		the dominant use of the information in the field may be by humans and
	may be by humans and not applications.		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 arises 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 it would cause an error condition.		presence of an OpenPGP field if it would cause an error condition.
	Since 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 typically contains the Key ID		the sender's OpenPGP key. The field typically contains the Key ID
	and the URL where the key can be retrieved.		and the URL where the key can be retrieved.
	skipping to change at page 4, line 31		skipping to change at page 4, line 31
	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; except as noted below. The provisions		in the middle of parameters; except as noted below. The provisions
	of MIME [RFC2231] also apply; in particular it deals with handling		of MIME Parameter Extensions [RFC2231] also apply; in particular,
	parameters of excessive length.		that document deals with handling parameters of excessive length.
	The OpenPGP header field is defined as below in the Augmented BNF		The OpenPGP header field is defined 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 refers the
	reader to the other documents for the definition of non-terminals.		reader to the other documents for the definition of non-terminals.
	Implementations MUST understand the "id", "url", and "preference"		Implementations MUST understand the "id", "url", and "preference"
	attributes. Parameter with unrecognized attributes MUST be ignored.		attributes. Parameter with unrecognized attributes MUST be ignored.
	The grammar permit unknown parameters to allow for future extensions.		The grammar permits unknown parameters to allow for future
	Each parameter attribute (e.g., "url") MUST NOT occur more than once		extensions. Each parameter attribute (e.g., "url") MUST NOT occur
	in any single instance of the OpenPGP field. The OpenPGP field		more than once in any single instance of the OpenPGP field. The
	itself MAY occur more than once in a single email (for example if the		OpenPGP field itself MAY occur more than once in a single email (for
	sender has multiple keys).		example if the sender has multiple keys).
	openpgp = "OpenPGP:" SP *CFWS o-params CRLF		openpgp = "OpenPGP:" SP o-params CRLF
	; CFWS is defined in RFC 2822.		; CFWS is defined in RFC 2822.
	; SP and CRLF are defined in RFC 5234.		; SP and CRLF are defined in RFC 5234.
	o-params = (o-parameter *CFWS *(";" *CFWS o-params))		o-params = (o-parameter *(";" o-parameter))
	o-parameter =		o-parameter = *CFWS "id" "=" id *CFWS
	("id" "=" id) /		/ *CFWS "url" "=" url *CFWS
	("url" "=" url) /		/ *CFWS "preference" "=" preference *CFWS
	("preference" "=" preference) /		/ *CFWS parameter *CFWS ; normally unused, for extensions
	parameter ; normally unused, for extensions
	; parameter is defined in RFC 2045.		; parameter is defined in RFC 2045.
	id = 8*HEXDIG		id = 1*(8HEXDIG)
	; HEXDIG is defined in RFC 5234.		; HEXDIG is defined in RFC 5234.
	; Matching of value is case-insensitive.		; Matching of value is case-insensitive.
	url = absoluteURI / quoted-url		url = absoluteURI / quoted-url
	; absoluteURI is defined in RFC 3986.		; absoluteURI is defined in RFC 3986.
	; If URL contains the character ';',		; If the URL contains the character ";",
	; the quoted-url form MUST be used.		; the quoted-url form MUST be used.
	quoted-url = DQUOTE absoluteURI DQUOTE		quoted-url = DQUOTE absoluteURI DQUOTE
	; DQUOTE is defined in RFC 5234.		; DQUOTE is defined in RFC 5234.
	preference = "sign" / "encrypt" / "signencrypt" / "unprotected"		preference = "sign" / "encrypt" / "signencrypt" / "unprotected"
	; Matching of values are case-insensitive.		; Matching of values is case-insensitive.
	3.1. Primary Key ID field: id		3.1. Primary Key ID field: id
	The "id" parameter, if present, MUST hold the Key ID or key		The "id" parameter, if present, MUST hold the Key ID or key
	fingerprint for the primary key. The value uses the hex [RFC4648]		fingerprint for the primary key. The value uses the hex [RFC4648]
	notation. The parameter value is case-insensitive.		notation. The parameter value is case-insensitive.
	The length of the field determine whether it denotes a Key ID (8 hex		The length of the field determines whether it denotes a Key ID (8 hex
	symbols), a long Key ID (16 hex symbols), a v3 key fingerprint (32		symbols), a long Key ID (16 hex symbols), a v3 key fingerprint (32
	hex symbols), or a v4 key fingerprint (40 hex symbols).		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=1234567890abcdef0123456789ABCDEF01234567 (v4 fingerprint)		id=1234567890abcdef0123456789ABCDEF01234567 (v4 fingerprint)
	id=1234567890ABCDEF0123456789ABCDEF (v3 fingerprint, deprecated)		id=1234567890ABCDEF0123456789ABCDEF (v3 fingerprint, deprecated)
	skipping to change at page 6, line 32		skipping to change at page 6, line 32
	If the URL contains the character ';' the entire URL MUST be quoted,		If the URL contains the character ';' the entire URL MUST be quoted,
	as illustrated in the example.		as illustrated in the example.
	3.3. Protection Preference Field: preference		3.3. Protection Preference Field: preference
	The "preference" parameter, if present, specify the quality of		The "preference" parameter, if present, specify the quality of
	protection preferred by the sender. The parameter value is case-		protection preferred by the sender. The parameter value is case-
	insensitive.		insensitive.
	The available values are as follows. A "unprotected" token means		The available values are as follows. A "unprotected" token means
	that the sender prefer not to receive OpenPGP protected e-mails. A		that the sender prefers not to receive OpenPGP protected e-mails. A
	"sign" token means that the sender prefer to receive digitally signed		"sign" token means that the sender prefers to receive digitally
	e-mails. A "encrypt" token means that the sender prefer to receive		signed e-mails. A "encrypt" token means that the sender prefers to
	encrypted e-mails. A "signencrypt" token means that the sender		receive encrypted e-mails. A "signencrypt" token means that the
	prefer to receive encrypted and signed e-mails.		sender prefers to receive encrypted and signed e-mails.
	Note that there is no normative requirement on the receiver to follow		Note that there is no normative requirement on the receiver to follow
	the stated preference.		the stated preference.
	For example:		For example:
	preference=sign		preference=sign
	preference=unprotected		preference=unprotected
	preference=ENCRYPT		preference=ENCRYPT
	skipping to change at page 7, line 31		skipping to change at page 7, line 31
	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"		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, Alfred Hoenes, Peter J. Holzer, Ingo Klocker, Werner
	Kupper, William Leibzon, Charles Lindsey, Aleksandar Milivojevic,		Koch, Jochen Kupper, William Leibzon, Charles Lindsey, Aleksandar
	Xavier Maillard, Greg Sabino Mullane, Tim Polk, Thomas Roessler,		Milivojevic, Xavier Maillard, Greg Sabino Mullane, Tim Polk, Thomas
	Moritz Schulte, Olav Seyfarth, David Shaw, Thomas Sjogren, Paul		Roessler, Moritz Schulte, Olav Seyfarth, David Shaw, Thomas Sjogren,
	Walker, and Steve Youngs. No doubt the list is incomplete. We		Paul Walker, and Steve Youngs. No doubt the list is incomplete. We
	apologize to 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. The OpenPGP header is neither secure nor intended to		public keys; it is neither secure nor intended to be. Since the
	be. Since the message header is easy to spoof, information contained		message header is easy to spoof, information contained in the header
	in the header should not be trusted. The information must be		should not be trusted. The information must be verified.
	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 automatically retrieve a key, the application MAY		in the field to automatically retrieve a key, the application MAY
	skipping to change at page 8, line 38		skipping to change at page 8, line 37
	can verify the liveness of each email address by checking if the URL		can verify the liveness of each email address by checking if the URL
	for each particular recipient has been retrieved. To protect against		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. This		the content between messages can be used as a covert channel. This
	is already possible using other header fields in email, and thus the		is already possible using other header fields in email, and thus the
	OpenPGP field do not introduce a new vulnerability here.		OpenPGP field does 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
	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. References		9. References
	9.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
End of changes. 25 change blocks.
	50 lines changed or deleted		48 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/