draft-josefsson-openpgp-mailnews-header-06.txt		draft-josefsson-openpgp-mailnews-header.txt
	Network Working Group A. Smasher		Network Working Group A. Smasher
	Internet-Draft S. Josefsson		Internet-Draft S. Josefsson
	Intended status: Informational May 20, 2008		Intended status: Informational May 2008
	Expires: November 21, 2008		Expires: November 2, 2008
	The "OpenPGP" mail and news header field		The "OpenPGP" mail and news header field
	draft-josefsson-openpgp-mailnews-header-06		draft-josefsson-openpgp-mailnews-header-07
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	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.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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 November 21, 2008.		This Internet-Draft will expire on November 2, 2008.
			Copyright Notice
			Copyright (c) 2008 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents in effect on the date of
			publication of this document (http://trustee.ietf.org/license-info).
			Please review these documents carefully, as they describe your rights
			and restrictions with respect to this document.
	Abstract		Abstract
	This document describes the "OpenPGP" mail and news header field.		This document describes the "OpenPGP" mail and news header field.
	The 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
	3.3. Protection Preference Field: preference . . . . . . . . . 6		3.3. Protection Preference Field: preference . . . . . . . . . 6
	4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 10		9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	9.2. Informative References . . . . . . . . . . . . . . . . . . 10		9.2. Informative References . . . . . . . . . . . . . . . . . . 10
	Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 11		Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 [RFC5322] 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.
	This document should be interpreted within the context of RFC 2822.		This document should be interpreted within the context of [RFC5322].
	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 [RFC2119].		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
	skipping to change at page 4, line 24		skipping to change at page 4, line 24
	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.
	Because the mail 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 in 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 5322).
	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.
	of MIME Parameter Extensions [RFC2231] also apply; in particular,
	that document deals with handling parameters of excessive length.
	The OpenPGP header field is defined 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 [RFC5322] 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 refers 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 permits unknown parameters to allow for future		The grammar permits unknown parameters to allow for future
	extensions. Each parameter attribute (e.g., "url") MUST NOT occur		extensions. Each parameter attribute (e.g., "url") MUST NOT occur
	more than once in any single instance of the OpenPGP field. The		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		OpenPGP field itself MAY occur more than once in a single email (for
	example if the sender has multiple keys).		example if the sender has multiple keys).
	openpgp = "OpenPGP:" SP o-params CRLF		openpgp = "OpenPGP:" o-params CRLF
	; CFWS is defined in RFC 2822.		; CFWS is defined in RFC 5322.
	; SP and CRLF are defined in RFC 5234.		; CRLF is defined in RFC 5234.
	o-params = (o-parameter *(";" o-parameter))		o-params = (o-parameter *(";" o-parameter))
	o-parameter = *CFWS "id" "=" id *CFWS		o-parameter = *CFWS "id" "=" id *CFWS
	/ *CFWS "url" "=" url *CFWS		/ *CFWS "url" "=" url *CFWS
	/ *CFWS "preference" "=" preference *CFWS		/ *CFWS "preference" "=" preference *CFWS
	/ *CFWS parameter *CFWS ; normally unused, for extensions		/ *CFWS parameter *CFWS ; normally unused, for extensions
	; parameter is defined in RFC 2045.		; parameter is defined in RFC 2045.
	id = 1*(8HEXDIG)		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 = folded-uri / quoted-url
	; absoluteURI is defined in RFC 3986.
	; If the 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 folded-uri DQUOTE
	; DQUOTE is defined in RFC 5234.		; DQUOTE is defined in RFC 5234.
			folded-uri = <absolute-URI, but free insertion of FWS permitted>
			; absoluteURI is defined in RFC 3986.
			; FWS is defined in RFC 5234.
	preference = "sign" / "encrypt" / "signencrypt" / "unprotected"		preference = "sign" / "encrypt" / "signencrypt" / "unprotected"
	; Matching of values is case-insensitive.		; Matching of values is case-insensitive.
			The folded-URI MAY contain folding whitespace (FWS, [RFC5322]), which
			is ignored. To convert a folded-URI to a absolute-URI, first apply
			standard [RFC5322] unfolding rules (replacing FWS with a single SP),
			and then delete any remaining un-encoded SP characters. Folding may
			be used to shorten long lines.
	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 determines 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).
	skipping to change at page 6, line 49		skipping to change at page 7, line 7
	the stated preference.		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.2 of RFC 5322, 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
	skipping to change at page 10, line 16		skipping to change at page 10, line 16
	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
	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
	Word Extensions:
	Character Sets, Languages, and Continuations", RFC 2231,
	November 1997.
	[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
	April 2001.
	[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.
			[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
			October 2008.
	9.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 12, line 4		skipping to change at line 433
	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)
	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
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	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
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
End of changes. 20 change blocks.
	32 lines changed or deleted		42 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/