draft-ietf-openpgp-mime-00.txt		draft-ietf-openpgp-mime-01.txt
	OpenPGP Working Group M. Elkins		OpenPGP Working Group M. Elkins
	draft-ietf-openpgp-mime-00.txt Network Associates, Inc.		draft-ietf-openpgp-mime-01.txt Network Associates, Inc.
	Obsoletes: 2015 D. Del Torto		Obsoletes: 2015 D. Del Torto
	CryptoRights Foundation		CryptoRights Foundation
	R. Levien		R. Levien
	University of California at Berkeley		University of California at Berkeley
	T. Roessler		T. Roessler
	February 2000		April 2000
	MIME Security with OpenPGP		MIME Security with OpenPGP
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	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 2, line 35		skipping to change at page 2, line 35
	document are to be interpreted as described in		document are to be interpreted as described in
	RFC 2119.		RFC 2119.
	2. OpenPGP data formats		2. OpenPGP data formats
	OpenPGP implementations can generate either ASCII armor (described in		OpenPGP implementations can generate either ASCII armor (described in
	[1]) or 8-bit binary output when encrypting data, generating a		[1]) or 8-bit binary output when encrypting data, generating a
	digital signature, or extracting public key data. The ASCII armor		digital signature, or extracting public key data. The ASCII armor
	output is the REQUIRED method for data transfer. This allows those		output is the REQUIRED method for data transfer. This allows those
	users who do not have the means to interpret the formats described in		users who do not have the means to interpret the formats described in
	this document to be able extract and use the OpenPGP information in		this document to be able to extract and use the OpenPGP information
	the message.		in the message.
	When the amount of data to be transmitted requires that it be sent in		When the amount of data to be transmitted requires that it be sent in
	many parts, the MIME message/partial mechanism SHOULD be used rather		many parts, the MIME message/partial mechanism SHOULD be used rather
	than the multipart ASCII armor OpenPGP format.		than the multipart ASCII armor OpenPGP format.
	3. Content-Transfer-Encoding restrictions		3. Content-Transfer-Encoding restrictions
	Multipart/signed and multipart/encrypted are to be treated by agents		Multipart/signed and multipart/encrypted are to be treated by agents
	as opaque, meaning that the data is not to be altered in any way [2],		as opaque, meaning that the data is not to be altered in any way [2],
	[7]. However, many existing mail gateways will detect if the next hop		[7]. However, many existing mail gateways will detect if the next hop
	skipping to change at page 3, line 26		skipping to change at page 3, line 26
	encoding, but restrict generation to the 7-bit format required by		encoding, but restrict generation to the 7-bit format required by
	this memo. This will allow future compatibility in the event the		this memo. This will allow future compatibility in the event the
	Internet SMTP framework becomes 8-bit friendly.		Internet SMTP framework becomes 8-bit friendly.
	4. OpenPGP encrypted data		4. OpenPGP encrypted data
	Before OpenPGP encryption, the data is written in MIME canonical		Before OpenPGP encryption, the data is written in MIME canonical
	format (body and headers).		format (body and headers).
	OpenPGP encrypted data is denoted by the "multipart/encrypted"		OpenPGP encrypted data is denoted by the "multipart/encrypted"
	content type, described in [1], and MUST have a "protocol" parameter		content type, described in [2], and MUST have a "protocol" parameter
	value of "application/pgp-encrypted". Note that the value of the		value of "application/pgp-encrypted". Note that the value of the
	parameter MUST be enclosed in quotes.		parameter MUST be enclosed in quotes.
	The multipart/encrypted MUST consist of exactly two parts. The first		The multipart/encrypted MUST consist of exactly two parts. The first
	MIME body part must have a content type of "application/pgp-		MIME body part must have a content type of "application/pgp-
	encrypted". This body contains the control information. A message		encrypted". This body contains the control information. A message
	complying with this standard MUST contain a "Version: 1" field in		complying with this standard MUST contain a "Version: 1" field in
	this body. Since the OpenPGP packet format contains all other		this body. Since the OpenPGP packet format contains all other
	information necessary for decrypting, no other information is		information necessary for decrypting, no other information is
	required here.		required here.
	skipping to change at page 4, line 42		skipping to change at page 4, line 42
	5. OpenPGP signed data		5. OpenPGP signed data
	OpenPGP signed messages are denoted by the "multipart/signed" content		OpenPGP signed messages are denoted by the "multipart/signed" content
	type, described in [2], with a "protocol" parameter which MUST have a		type, described in [2], with a "protocol" parameter which MUST have a
	value of "application/pgp-signature" (MUST be quoted) if the message		value of "application/pgp-signature" (MUST be quoted) if the message
	contains a single signature, or "multipart/mixed" if the message		contains a single signature, or "multipart/mixed" if the message
	contains two or more signatures [8]. In the latter case, each		contains two or more signatures [8]. In the latter case, each
	OpenPGP signature is denoted using the content-type "application/pgp-		OpenPGP signature is denoted using the content-type "application/pgp-
	signature" inside the multipart/mixed.		signature" inside the multipart/mixed.
	var1 The "micalg" parameter MUST contain exactly one hash-symbol.		The "micalg" parameter for the "application/pgp-signature" protocol
	This hash-symbol identifies the message integrity check (MIC)		MUST contain exactly one hash-symbol of the format "pgp-<hash-
	algorithm used to generate the subsequent signature. Hash-		symbol>", where <hash-symbol> identifies the Message Integrity Check
	symbols are constructed from the text names registered in [4]		(MIC) algorithm used to generate the signature. Hash-symbols are
	or according to the mechanism defined in that document by		constructed from the text names registered in [1] or according to the
	converting the text name to lower case and prefixing it with		mechanism defined in that document by converting the text name to
	the four characters "pgp-".		lower case and prefixing it with the four characters "pgp-".
	var1 Currently defined values are "pgp-md5", "pgp-sha1", "pgp-
	ripemd160", "pgp-md2", "pgp-tiger192", and "pgp-haval-5-160".
	var2 The "micalg" parameter for the "application/pgp-signature"
	protocol MUST have a value of "pgp-<hash-symbol>", where
	<hash-symbol> identifies the Message Integrity Check (MIC)
	algorithm used to generate the signature. The currently-
	defined values for <hash-symbol> are "md5" for the MD5
	checksum, and "sha1" for the SHA-1 algorithm (FIPS 180-1) [5]:
	compliant implementations MUST be able to accept and generate
	MD5 signature-hashes and MUST be able to accept and generate
	SHA-1 signature-hashes.
	var2 Note: new <hash-symbol> values may be registered by sending		Currently defined values are "pgp-md5", "pgp-sha1", "pgp- ripemd160",
	email to <new-pgp-hash-value-reg@iana.org>. The listing of		"pgp-md2", "pgp-tiger192", and "pgp-haval-5-160".
	current values may be obtained by sending email to <pgp-hash-
	values@iana.org>.
	The multipart/signed body MUST consist of exactly two parts. The		The multipart/signed body MUST consist of exactly two parts. The
	first part contains the signed data in MIME canonical format,		first part contains the signed data in MIME canonical format,
	including a set of appropriate content headers describing the data.		including a set of appropriate content headers describing the data.
	The second body MUST contain the OpenPGP digital signature(s). It		The second body MUST contain the OpenPGP digital signature(s). It
	MUST be labeled with a content type of "application/pgp-signature" if		MUST be labeled with a content type of "application/pgp-signature" if
	there is a single signature, or "multipart/mixed" if there are two or		there is a single signature, or "multipart/mixed" if there are two or
	more signatures.		more signatures.
	skipping to change at page 6, line 8		skipping to change at page 5, line 39
	beginning with "From" to distinguish this case, invalidating the		beginning with "From" to distinguish this case, invalidating the
	signature. In addition, line endings in the encoded data MUST		signature. In addition, line endings in the encoded data MUST
	use the canonical <CR><LF> sequence where appropriate (note that		use the canonical <CR><LF> sequence where appropriate (note that
	the canonical line ending may or may not be present on the last		the canonical line ending may or may not be present on the last
	line of encoded data and MUST NOT be included in the signature		line of encoded data and MUST NOT be included in the signature
	if absent).		if absent).
	(3) MIME content headers are then added to the body, each ending		(3) MIME content headers are then added to the body, each ending
	with the canonical <CR><LF> sequence.		with the canonical <CR><LF> sequence.
	(4) As described in [1], the digital signature MUST be calculated		(4) As described in [2], the digital signature MUST be calculated
	over both the data to be signed and its set of content headers.		over both the data to be signed and its set of content headers.
	(5) The signature MUST be generated detached from the signed data so		(5) The signature MUST be generated detached from the signed data so
	that the process does not alter the signed data in any way.		that the process does not alter the signed data in any way.
	Note: The accepted OpenPGP convention is for signed data to end a		Note: The accepted OpenPGP convention is for signed data to end
	<CR><LF> sequence. Note that the <CR><LF> sequence immediately		with a <CR><LF> sequence. Note that the <CR><LF> sequence
	preceding a MIME boundary delimiter line is considered to be part		immediately preceding a MIME boundary delimiter line is considered
	of the delimiter in [3], 5.1. Thus, it is not part of the signed		to be part of the delimiter in [3], 5.1. Thus, it is not part of
	data preceding the delimiter line. An implementation which elects		the signed data preceding the delimiter line. An implementation
	to adhere to OpenPGP convention has to make sure it inserts a		which elects to adhere to OpenPGP convention has to make sure it
	<CR><LF> pair on the last line of the data to be signed and		inserts a <CR><LF> pair on the last line of the data to be signed
	transmitted (signed message and transmitted message MUST be		and transmitted (signed message and transmitted message MUST be
	identical).		identical).
	Example message:		Example message:
	From: Michael Elkins <elkins@aero.org>		From: Michael Elkins <elkins@aero.org>
	To: Michael Elkins <elkins@aero.org>		To: Michael Elkins <elkins@aero.org>
	Mime-Version: 1.0		Mime-Version: 1.0
	Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;		Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
	protocol="application/pgp-signature"		protocol="application/pgp-signature"
	skipping to change at page 9, line 40		skipping to change at page 9, line 40
	9. Notes		9. Notes
	"PGP" and "Pretty Good Privacy" are registered trademarks of Network		"PGP" and "Pretty Good Privacy" are registered trademarks of Network
	Associates, Inc.		Associates, Inc.
	10. Acknowledgements		10. Acknowledgements
	This draft document relies on the work of the IETF's OpenPGP Working		This draft document relies on the work of the IETF's OpenPGP Working
	Group's definitions of the OP Message Format. The OP message format		Group's definitions of the OP Message Format. The OP message format
	is currently described in RFC 2440 [4].		is currently described in RFC 2440 [1].
	Special thanks are due: to Philip Zimmermann for his original and		Special thanks are due: to Philip Zimmermann for his original and
	ongoing work on PGP; to Charles Breed for originally proposing the		ongoing work on PGP; to Charles Breed for originally proposing the
	formation of the OpenPGP Working Group; and to Steve Schoenfeld for		formation of the OpenPGP Working Group; and to Steve Schoenfeld for
	helpful feedback during the draft process. The authors would also		helpful feedback during the draft process. The authors would also
	like to thank the engineers at Pretty Good Privacy, Inc (now Network		like to thank the engineers at Pretty Good Privacy, Inc (now Network
	Associates, Inc), including Colin Plumb, Hal Finney, Jon Callas, Mark		Associates, Inc), including Colin Plumb, Hal Finney, Jon Callas, Mark
	Elrod, Mark Weaver and Lloyd Chambers, for their technical		Elrod, Mark Weaver and Lloyd Chambers, for their technical
	commentary.		commentary.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/