draft-josefsson-openpgp-mailnews-header-01.txt		draft-josefsson-openpgp-mailnews-header-02.txt
	Network Working Group A. Smasher		Network Working Group A. Smasher
	Internet-Draft S. Josefsson		Internet-Draft S. Josefsson
	Expires: November 26, 2005 May 25, 2005		Expires: March 27, 2006 September 23, 2005
	The OpenPGP mail and news header		The OpenPGP mail and news header
	draft-josefsson-openpgp-mailnews-header-01		draft-josefsson-openpgp-mailnews-header-02
	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 33
	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 26, 2005.		This Internet-Draft will expire on March 27, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document describes the OpenPGP mail and news header field. The		This document describes the OpenPGP mail and news header field. The
	field provide information about the sender's OpenPGP key.		field provide information about the sender's OpenPGP key.
	See <http://josefsson.org/openpgp-header/> for more information.		See <http://josefsson.org/openpgp-header/> for more information.
	Table of Contents		Table of Contents
	1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Background and Motivation . . . . . . . . . . . . . . . . . 3		2. Background and Motivation . . . . . . . . . . . . . . . . . . 3
	3. OpenPGP Header Field . . . . . . . . . . . . . . . . . . . . 4		3. OpenPGP Header Field . . . . . . . . . . . . . . . . . . . . . 4
	3.1 Primary Key ID field: id . . . . . . . . . . . . . . . . . 5		3.1. Primary Key ID field: id . . . . . . . . . . . . . . . . . 5
	3.2 Key URL field: url . . . . . . . . . . . . . . . . . . . . 5		3.2. Key URL field: url . . . . . . . . . . . . . . . . . . . . 5
	4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.3. Protection Preference Field: preference . . . . . . . . . 6
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8. Security Considerations . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7		8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	10. Copying conditions . . . . . . . . . . . . . . . . . . . . . 8		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		10. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 9
	11.1 Normative References . . . . . . . . . . . . . . . . . . 8		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	11.2 Informative References . . . . . . . . . . . . . . . . . 9		11.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9		11.2. Informative References . . . . . . . . . . . . . . . . . . 10
	Intellectual Property and Copyright Statements . . . . . . . 10		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.
	This header should be considered "informational" (and "optional"),		This header should be considered "informational" (and "optional"),
	and be suitable for both mail [8] and netnews [1] messages. This		and be suitable for both mail [8] and netnews [1] messages. This
	header should be used to provide information about the sender's		header should be used to provide information about the sender's
	OpenPGP [7] key. This header MAY be used in any message.		OpenPGP [7] key. This header 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.
	skipping to change at page 4, line 34		skipping to change at page 4, line 36
	In the Augmented BNF [5] notation, an OpenPGP header field is defined		In the Augmented BNF [5] notation, an OpenPGP header field is defined
	as below. By itself, however, this grammar is incomplete. It refers		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		by name to several syntax rules that are defined by RFC 2822 and the
	URI syntax document [6]. Rather than reproduce those definitions		URI syntax document [6]. Rather than reproduce those definitions
	here, and risk unintentional differences between the two, this		here, and risk unintentional differences between the two, this
	document refer the reader to RFC 2822 and RFC 2396 for the definition		document refer the reader to RFC 2822 and RFC 2396 for the definition
	of non-terminals.		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. This header SHOULD NOT appear more than
	once within a message. A given parameter type (i.e., "id" or "url")		once within a message. A given parameter type (i.e., "id", "url" or
	may appear no more than once.		"preference") MUST NOT occur more than once.
	openpgp := "OpenPGP:" id-or-url /		openpgp := "OpenPGP:"
	(openpgp-parameter *(";" openpgp-parameter))		(openpgp-parameter *(";" openpgp-parameter))
	CRLF		CRLF
	id-or-url := id / url
	id := *HEXDIG		id := *HEXDIG
	url := absoluteURI ; Defined in RFC 2396.		url := absoluteURI ; Defined in RFC 2396.
			preference := "sign" / "encrypt" / "signencrypt" / "unprotected"
	openpgp-parameter		openpgp-parameter
	:= ("id" "=" id) /		:= ("id" "=" id) /
	("url" "=" url) /		("url" "=" url) /
			("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 hexadecimal [14] 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 [12] or FTP [9]. 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
			The "preference" attribute=value pair, if present, specify the
			quality of protection preferred by the sender. The available choices
			are "unprotected" which means that the sender prefer not to receive
			OpenPGP protected e-mails. A "sign" token means that the sender
			prefer to receive digitally signed e-mails. A "encrypt" token means
			that the sender prefer to receive digitally encrypted e-mails. A
			"signencrypt" token means that the sender prefer to receive digitally
			encrypted and signed e-mails. Note that there is no technical
			requirement on the receiver to follow the stated preference.
			For example:
			preference=sign
			preference="unprotected"
			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 header field bodies 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 ways in which this header may be used.
	This list is not meant to be exhaustive, but do reflect expected		This list is not meant to be exhaustive, but do reflect expected
	typical usages.		typical usages.
	OpenPGP: 12345678
	OpenPGP: id=12345678		OpenPGP: id=12345678
	OpenPGP: http://example.com/key.txt
	OpenPGP: url=http://example.com/key.txt		OpenPGP: url=http://example.com/key.txt
			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
	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)
	6. Open Issues		6. Open Issues
	Should there be a "supports" field, that signal whether the sender		Should there be a "supports" field, that signal whether the sender
	support inline PGP or PGP/MIME? As in supports="inline, mime" or		support inline PGP or PGP/MIME? As in supports="inline, mime" or
	similar. Should it be in preferred priority order?		similar. Should it be in preferred priority order? This draft
			tentatively closes this issue by ignoring the matter, until someone
			proposes text.
	The ABNF definition is known to be under-specified.		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		Peter J. Holzer, Ingo Klocker, Werner Koch, Jochen Kupper, Charles
	Lindsey, Aleksandar Milivojevic, Xavier Maillard, Greg Sabino		Lindsey, Aleksandar Milivojevic, Xavier Maillard, Greg Sabino
	Mullane, Thomas Roessler, Moritz Schulte, Olav Seyfarth, Thomas		Mullane, Thomas Roessler, Moritz Schulte, Olav Seyfarth, Thomas
	skipping to change at page 8, line 24		skipping to change at page 9, line 24
	makes no guarantees and is not responsible for any damage		makes no guarantees and is not responsible for any damage
	resulting from its use. The authors grants irrevocable		resulting from its use. The authors grants irrevocable
	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] Horton, M. and R. Adams, "Standard for interchange of USENET
	messages", RFC 1036, December 1987.		messages", RFC 1036, December 1987.
	[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[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		[3] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
	Extensions: Character Sets, Languages, and Continuations",		Extensions: Character Sets, Languages, and Continuations",
	skipping to change at page 9, line 5		skipping to change at page 10, line 5
	[6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifiers (URI): Generic Syntax", RFC 2396,		Resource Identifiers (URI): Generic Syntax", RFC 2396,
	August 1998.		August 1998.
	[7] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP		[7] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP
	Message Format", RFC 2440, November 1998.		Message Format", RFC 2440, November 1998.
	[8] Resnick, P., "Internet Message Format", RFC 2822, April 2001.		[8] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
	11.2 Informative References		11.2. Informative References
	[9] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,		[9] 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",		[10] Eastlake, D., "Domain Name System Security Extensions",
	RFC 2535, March 1999.		RFC 2535, March 1999.
	[11] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,		[11] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
	June 1999.		June 1999.
	skipping to change at page 9, line 33		skipping to change at page 11, line 9
	RFC 3548, July 2003.		RFC 3548, July 2003.
	[15] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[15] 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.
	Authors' Addresses		Authors' Addresses
	Atom Smasher		Atom Smasher
	Email: [email protected] (0x762A3B98A3C396C9C6B7582AB88D52E4D9F57808)		Email: [email protected] (762A3B98A3C396C9C6B7582AB88D52E4D9F57808)
	Simon Josefsson		Simon Josefsson
	Email: [email protected] (0x0424D4EE81A0E3D119C6F835EDA21E94B565716F)		Email: [email protected] (0424D4EE81A0E3D119C6F835EDA21E94B565716F)
	Intellectual Property Statement		Intellectual Property Statement
	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
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/