draft-josefsson-openpgp-mailnews-header-00.txt		draft-josefsson-openpgp-mailnews-header-01.txt
	Network Working Group A. Smasher		Network Working Group A. Smasher
	Internet-Draft S. Josefsson		Internet-Draft S. Josefsson
	Expires: July 8, 2005 January 7, 2005		Expires: November 26, 2005 May 25, 2005
	The OpenPGP mail and news header		The OpenPGP mail and news header
	draft-josefsson-openpgp-mailnews-header-00		draft-josefsson-openpgp-mailnews-header-01
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		By submitting this Internet-Draft, each author represents that any
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		applicable patent or other IPR claims of which he or she is aware
	author represents that any applicable patent or other IPR claims of		have been or will be disclosed, and any of which he or she becomes
	which he or she is aware have been or will be disclosed, and any of		aware will be disclosed, in accordance with Section 6 of BCP 79.
	which he or she become aware will be disclosed, in accordance with
	RFC 3668.
	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		other groups may also distribute working documents as Internet-
	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 July 8, 2005.		This Internet-Draft will expire on November 26, 2005.
	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 Primary Key Algorithm field: algo . . . . . . . . . . . . 5		3.2 Key URL field: url . . . . . . . . . . . . . . . . . . . . 5
	3.3 Primary Key Size field: size . . . . . . . . . . . . . . . 5		4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.4 Key URL field: url . . . . . . . . . . . . . . . . . . . . 6		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.5 Key Creation Date field: created . . . . . . . . . . . . . 6		6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. Security Considerations . . . . . . . . . . . . . . . . . . 6
	6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7		10. Copying conditions . . . . . . . . . . . . . . . . . . . . . 8
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 7		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 8		11.1 Normative References . . . . . . . . . . . . . . . . . . 8
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		11.2 Informative References . . . . . . . . . . . . . . . . . 9
	10.1 Normative References . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
	10.2 Informative References . . . . . . . . . . . . . . . . . . . 8		Intellectual Property and Copyright Statements . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
	Intellectual Property and Copyright Statements . . . . . . . . 10
	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 [6] 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 [5] 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.
	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 [2].		document are to be interpreted as described in RFC 2119 [4].
	2. Background and Motivation		2. Background and Motivation
	There are quite a few PGP and GnuPG users who add headers with		There are quite a few PGP and GnuPG users who add headers with
	information about the sender's OpenPGP key. Headers in current use		information about the sender's OpenPGP key. Headers in current use
	include "X-PGP:", "X-PGP-Key:", "X-Request-PGP:", "X-PGP-KeyID:", and		include "X-PGP:", "X-PGP-Key:", "X-Request-PGP:", "X-PGP-KeyID:", and
	"X-PGP-Fingerprint:". The headers lack standardization, which		"X-PGP-Fingerprint:". The headers lack standardization, which
	prevent them from being reliably parsed automatically by		prevent them from being reliably parsed automatically by
	applications, rather than manually parsed by humans.		applications, rather than manually parsed by humans.
	skipping to change at page 4, line 11		skipping to change at page 4, line 11
	applications do not trigger error messages that may annoy the user,		applications do not trigger error messages that may annoy the user,
	when an error condition arise during handling of the OpenPGP header.		when an error condition arise during handling of the OpenPGP header.
	It is generally recommended that an implementation ignore the		It is generally recommended that an implementation ignore the
	presence of the OpenPGP header if an error condition occur. Since		presence of the OpenPGP header if an error condition occur. Since
	the header is optional, this approach should not be difficult to		the header is optional, this approach should not be difficult to
	implement. The philosophy here is to enable an enhanced user		implement. The philosophy here is to enable an enhanced user
	experience. Error messages rarely contribute to that goal.		experience. Error messages rarely contribute to that goal.
	3. OpenPGP Header Field		3. OpenPGP Header Field
	This header, if used, is intended to present characteristics of the		This header is intended to present characteristics of the sender's
	sender's OpenPGP key, such as the primary key ID (or fingerprint),		OpenPGP key. It may contain the Key ID and the URL where the key can
	algorithm, size and URL where the key can be found. This header is		be retrieved.
	of a "structured" type (see section 2.2.2 of RFC 2822). In general,
	the structure consist of one or more attribute and value pairs. The
	terminology and format of the header was inspired by MIME [8].
	This header SHOULD NOT appear more than once within a message.		This header is of a "structured" type (see section 2.2.2 of RFC
			2822). In general, the structure consist of one or more parameters,
			each consisting of one attribute and one value. The terminology and
			format of the header was inspired by MIME [2]. The various
			provisions of RFC 2045 apply. In particular, the value part of all
			parameters may be quoted; whitespace, foldoing and comments may occur
			in the middle of parameters. The provisions of MIME [3] also apply;
			in particular it deals with handling parameters of excessive length.
	In the Augmented BNF [3] 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 [4]. 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.
	openpgp := "OpenPGP:" id-or-url / (parameter *(";" parameter))		Unrecognized parameters MUST be ignored. The grammar permit them to
			allow for future extensions. This header SHOULD NOT appear more than
			once within a message. A given parameter type (i.e., "id" or "url")
			may appear no more than once.
			openpgp := "OpenPGP:" id-or-url /
			(openpgp-parameter *(";" openpgp-parameter))
	CRLF		CRLF
	id-or-url := id / url		id-or-url := id / url
	id := ["0x"] (4*HEXDIG / 8*HEXDIG / 32*HEXDIG / 40*HEXDIG)		id := *HEXDIG
	url := absoluteURI ; Defined in RFC 2396.		url := absoluteURI ; Defined in RFC 2396.
	algo := *DIGIT ; Value in RFC 2440 section 9.1.		openpgp-parameter
			:= ("id" "=" id) /
	size := *DIGIT ; Primary key size in bits.
	created := *DIGIT ; Correspond to four-octet number in
	; RFC 2440 V3/V4 key packet that indicate
	; the time the key was created, expressed as
	; an unsigned decimal integer.
	parameter := ("id" "=" id) /
	("url" "=" url) /		("url" "=" url) /
	("algo" "=" algo) /		parameter ; See RFC 2045 for definition of parameter.
	("size" "=" size) /
	("created" "=" created)
	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 MAY be prefixed with "0x". The value MUST		key ID. The value MUST identify the key ID (in either short or long
	identify the key ID (in either short or long form) or the		form) or the fingerprint, all using the hexadecimal [14] notation.
	fingerprint, all using the hexadecimal [13] notation.
	A short key ID is a 32 bit key ID, represented as 8 characters.
	A long key ID is a 64 bit key ID, represented as 16 characters.
	A v4 fingerprint is a 160 bit key ID, represented as 40 characters.
	A v3 fingerprint is a 128 bit key ID, represented as 32 characters.
	Note that each of the following examples includes a comment, which is
	optional.
	id=12345678 (short key ID, no 0x prefix)
	id=0x12345678 (short key ID)
	id=0x1234567890ABCDEF (long key ID)
	id=0x1234567890ABCDEF01234567890ABCDEF0123456 (v4 fingerprint)
	id=0x1234567890ABCDEF01234567890ABCDE (v3 fingerprint)
	3.2 Primary Key Algorithm field: algo
	The "algo" attribute=value pair, if present, MUST specify the		The length of the field imply the kind of key id, i.e., short or long
	algorithm of the primary key. The algorithm of the primary key MUST		form, or a v3 or v4 key.
	be presented as the value defined in section 9.1 of RFC 2440 (Public
	Key Algorithms). The value MUST be presented as an integer in
	decimal notation.
	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.
	algo=1 (RSA)		id=12345678 (short key ID)
	algo=17 (DSA)		id=1234567890ABCDEF (long key ID)
			id=1234567890ABCDEF01234567890ABCDEF0123456 (v4 fingerprint)
	3.3 Primary Key Size field: size		id=1234567890ABCDEF01234567890ABCDE (v3 fingerprint, deprecated)
	The "size" attribute=value pair, if present, MUST specify the size of
	the primary key. The size of the primary key MUST be presented as
	the number of bits in the key's modulus. The value MUST be presented
	as an integer in decimal notation.
	Note that one of the following examples includes a comment, which is
	optional.
	size=1024
	size=2048 (bits)
	3.4 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 [11] or FTP [7]. 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.5 Key Creation Date field: created
	This "created" attribute=value pair, if present, MUST define the
	creation date of the primary key. The creation date of the primary
	key MUST be presented as specified in section 5.5.2 of RFC2440
	(Public Key Packet Formats). The value MUST be presented as a
	integer in decimal notation.
	Note that the following example includes a comment, which is
	optional.
	created=1104629466 (Sun Jan 2 01:31:06 UTC 2005)
	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=0xB565716F (key stored on non-networked laptop)		id=B565716F (key stored on non-networked laptop)
	id=0x12345678; algo=1 (RSA Encrypt or Sign)		id=12345678 (1024 bit RSA Key for Encrypt or Sign)
	id=0xABCD0123; created=1104629115 (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 of examples is not meant to be exhaustive.		This list is not meant to be exhaustive, but do reflect expected
			typical usages.
	OpenPGP: id=0x12345678		OpenPGP: 12345678
	OpenPGP: id=0x12345678; algo=1 (RSA); size=2048		OpenPGP: id=12345678
			OpenPGP: http://example.com/key.txt
	OpenPGP: url=http://example.com/key.txt		OpenPGP: url=http://example.com/key.txt
	OpenPGP: url=http://example.com/key.txt;		OpenPGP: url=http://example.com/key.txt; id=12345678
	id=0x12345678 (this key is only used at the office)		OpenPGP: id=12345678; url=http://example.com/key.txt
			OpenPGP: url=http://example.com/key.txt (down 2-3pm UTC);
			id=12345678 (this key is only used at the office)
	6. Open Issues		6. Open Issues
	Should the algo/size/created fields be included? They are supposedly
	only there for v3 keys.
	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?
			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, Peter J.		alphabetical order) Christian Biere, Patrick Brunschwig, Jon Callas,
	Holzer, Ingo Klocker, Werner Koch, Jochen Kupper, Aleksandar		Peter J. Holzer, Ingo Klocker, Werner Koch, Jochen Kupper, Charles
	Milivojevic, Xavier Maillard, Greg Sabino Mullane, Thomas Roessler,		Lindsey, Aleksandar Milivojevic, Xavier Maillard, Greg Sabino
	Moritz Schulte, Thomas Sjogren, Paul Walker, and Steve Youngs. No		Mullane, Thomas Roessler, Moritz Schulte, Olav Seyfarth, Thomas
	doubt the list is incomplete. We apologize to anyone we left out.		Sjogren, Paul Walker, and Steve Youngs. No doubt the list is
			incomplete. We apologize to anyone we left out.
	8. Security Considerations		8. Security Considerations
	These headers are intended to be a convenience in locating public		These headers are intended to be a convenience in locating public
	keys: They are neither secure nor intended to be. Since header		keys: They are neither secure nor intended to be. Since header
	information is easy to spoof, information contained in headers should		information is easy to spoof, information contained in headers should
	not be trusted: The information must be verified. How the		not be trusted: The information must be verified. How the
	information is verified is left as an exercise for the reader.		information is verified is left as an exercise for the reader.
	Applications that interpret the data within this header MUST NOT		Applications that interpret the data within this header MUST NOT
	skipping to change at page 8, line 8		skipping to change at page 7, line 8
	SHOULD alert the user that this information is not a substitute for		SHOULD alert the user that this information is not a substitute for
	personally verifying keys and being a part of the web of trust.		personally verifying keys and being a part of the web of trust.
	If an application receives a signed message and uses the information		If an application receives a signed message and uses the information
	in this header to retrieve a key, the application MAY ignore the		in this header to retrieve a key, the application MAY ignore the
	retrieved key if it is not the same key used to sign the message.		retrieved key if it is not the same key used to sign the message.
	This SHOULD be done before the newly retrieved key is imported into		This SHOULD be done before the newly retrieved key is imported into
	the user's keyring.		the user's keyring.
	The use of HTTPS [12], DNSSEC [9], SMTP STARTTLS [10], and other		The use of HTTPS [13], DNSSEC [10], SMTP STARTTLS [11], and other
	secure protocols, may enhance the security of information conveyed		secure protocols, may enhance the security of information conveyed
	through this header, but does not guarantee any level of security or		through this header, but does not guarantee any level of security or
	authenticity. Developers and users must remain aware of this.		authenticity. Developers and users must remain aware of this.
			Version 3 OpenPGP keys can be created with a chosen key id (aka "the
			0xDEADBEEF attack"). Verifying the Key ID of a retrived key against
			the one provided in this header is thus not sufficient to protect
			against a man-in-the-middle attack. Instead, the web-of-trust
			mechanism should be used.
			If an attacker wants to check the validity of Email addresses, he
			might send out junk email to arbitrary addresses and collect those
			that report back to the crafted OpenPGP URL. To protect against
			this, implementations MUST inform the user of that potential privacy
			issue when retrieving keys from an URL provided by the mail headers
			of an 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.
	Given the flexibility of the syntax of the header, slightly varying		Given the flexibility of the syntax of the header, slightly varying
	the content between messages can be used as a covert channel.		the content between messages can be used as a covert channel.
	9. Copying conditions		9. IANA Considerations
			The IANA is asked to register the OpenPGP header, using the template
			as follows, in accordance with RFC 3864 [15].
			Header field name: OpenPGP
			Applicable protocol: mail, netnews
			Status: informational
			Author/Change controller: IETF
			Specification document(s): This document.
			Related information: None
			10. Copying conditions
	In addition to the IETF/ISOC copying conditions, the following		In addition to the IETF/ISOC copying conditions, the following
	statement grant third parties further rights to this document.		statement grant third parties further rights to this document.
	Copyright (C) 2004 Atom Smasher		Copyright (C) 2004 Atom Smasher
	Copyright (C) 2004, 2005 Simon Josefsson		Copyright (C) 2004, 2005 Simon Josefsson
	Copying and distribution of the work, with or without		Regarding this entire document or any portion of it, the authors
	modification, are permitted in any medium without royalty		makes no guarantees and is not responsible for any damage
	provided the copyright notice and this notice are preserved.		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		11. References
	10.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] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
			Extensions (MIME) Part One: Format of Internet Message Bodies",
			RFC 2045, November 1996.
			[3] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
			Extensions: Character Sets, Languages, and Continuations",
			RFC 2231, November 1997.
			[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", RFC 2234, November 1997.		Specifications: ABNF", RFC 2234, November 1997.
	[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource		[6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Identifiers (URI): Generic Syntax", RFC 2396, August 1998.		Resource Identifiers (URI): Generic Syntax", RFC 2396,
			August 1998.
	[5] 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.
	[6] Resnick, P., "Internet Message Format", RFC 2822, April 2001.		[8] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
	10.2 Informative References		11.2 Informative References
	[7] 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.
	[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[10] Eastlake, D., "Domain Name System Security Extensions",
	Extensions (MIME) Part One: Format of Internet Message Bodies",		RFC 2535, March 1999.
	RFC 2045, November 1996.
	[9] Eastlake, D., "Domain Name System Security Extensions", RFC
	2535, March 1999.
	[10] 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.
	[11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,		[12] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
	Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --		Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
	HTTP/1.1", RFC 2616, June 1999.		HTTP/1.1", RFC 2616, June 1999.
	[12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.		[13] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
	[13] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",		[14] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
	RFC 3548, July 2003.		RFC 3548, July 2003.
			[15] Klyne, G., Nottingham, M., and J. Mogul, "Registration
			Procedures for Message Header Fields", BCP 90, RFC 3864,
			September 2004.
	Authors' Addresses		Authors' Addresses
	Atom Smasher		Atom Smasher
	EMail: [email protected] (0x762A3B98A3C396C9C6B7582AB88D52E4D9F57808)		Email: [email protected] (0x762A3B98A3C396C9C6B7582AB88D52E4D9F57808)
	Simon Josefsson		Simon Josefsson
	EMail: [email protected] (0x0424D4EE81A0E3D119C6F835EDA21E94B565716F)		Email: [email protected] (0x0424D4EE81A0E3D119C6F835EDA21E94B565716F)
	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/