--- 1/draft-ietf-openpgp-mime-00.txt 2006-02-05 00:55:21.000000000 +0100 +++ 2/draft-ietf-openpgp-mime-01.txt 2006-02-05 00:55:21.000000000 +0100 @@ -1,18 +1,19 @@ + 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 CryptoRights Foundation R. Levien University of California at Berkeley T. Roessler - February 2000 + April 2000 MIME Security with OpenPGP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -68,22 +69,22 @@ document are to be interpreted as described in RFC 2119. 2. OpenPGP data formats OpenPGP implementations can generate either ASCII armor (described in [1]) or 8-bit binary output when encrypting data, generating a digital signature, or extracting public key data. The ASCII armor output is the REQUIRED method for data transfer. This allows those 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 - the message. + this document to be able to extract and use the OpenPGP information + in the message. 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 than the multipart ASCII armor OpenPGP format. 3. Content-Transfer-Encoding restrictions 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], [7]. However, many existing mail gateways will detect if the next hop @@ -108,21 +109,21 @@ encoding, but restrict generation to the 7-bit format required by this memo. This will allow future compatibility in the event the Internet SMTP framework becomes 8-bit friendly. 4. OpenPGP encrypted data Before OpenPGP encryption, the data is written in MIME canonical format (body and headers). 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 parameter MUST be enclosed in quotes. The multipart/encrypted MUST consist of exactly two parts. The first MIME body part must have a content type of "application/pgp- encrypted". This body contains the control information. A message complying with this standard MUST contain a "Version: 1" field in this body. Since the OpenPGP packet format contains all other information necessary for decrypting, no other information is required here. @@ -162,45 +163,30 @@ 5. OpenPGP signed data OpenPGP signed messages are denoted by the "multipart/signed" content type, described in [2], with a "protocol" parameter which MUST have a value of "application/pgp-signature" (MUST be quoted) if the message contains a single signature, or "multipart/mixed" if the message contains two or more signatures [8]. In the latter case, each OpenPGP signature is denoted using the content-type "application/pgp- signature" inside the multipart/mixed. -var1 The "micalg" parameter MUST contain exactly one hash-symbol. - This hash-symbol identifies the message integrity check (MIC) - algorithm used to generate the subsequent signature. Hash- - symbols are constructed from the text names registered in [4] - or according to the mechanism defined in that document by - converting the text name to 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-", where - identifies the Message Integrity Check (MIC) - algorithm used to generate the signature. The currently- - defined values for 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. + The "micalg" parameter for the "application/pgp-signature" protocol + MUST contain exactly one hash-symbol of the format "pgp-", where identifies the Message Integrity Check + (MIC) algorithm used to generate the signature. Hash-symbols are + constructed from the text names registered in [1] or according to the + mechanism defined in that document by converting the text name to + lower case and prefixing it with the four characters "pgp-". -var2 Note: new values may be registered by sending - email to . The listing of - current values may be obtained by sending email to . + Currently defined values are "pgp-md5", "pgp-sha1", "pgp- ripemd160", + "pgp-md2", "pgp-tiger192", and "pgp-haval-5-160". The multipart/signed body MUST consist of exactly two parts. The first part contains the signed data in MIME canonical format, including a set of appropriate content headers describing the data. The second body MUST contain the OpenPGP digital signature(s). It 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 more signatures. @@ -222,34 +208,34 @@ beginning with "From" to distinguish this case, invalidating the signature. In addition, line endings in the encoded data MUST use the canonical sequence where appropriate (note that 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 if absent). (3) MIME content headers are then added to the body, each ending with the canonical 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. (5) The signature MUST be generated detached from the signed data so that the process does not alter the signed data in any way. - Note: The accepted OpenPGP convention is for signed data to end a - sequence. Note that the sequence immediately - preceding a MIME boundary delimiter line is considered to be part - of the delimiter in [3], 5.1. Thus, it is not part of the signed - data preceding the delimiter line. An implementation which elects - to adhere to OpenPGP convention has to make sure it inserts a - pair on the last line of the data to be signed and - transmitted (signed message and transmitted message MUST be + Note: The accepted OpenPGP convention is for signed data to end + with a sequence. Note that the sequence + immediately preceding a MIME boundary delimiter line is considered + to be part of the delimiter in [3], 5.1. Thus, it is not part of + the signed data preceding the delimiter line. An implementation + which elects to adhere to OpenPGP convention has to make sure it + inserts a pair on the last line of the data to be signed + and transmitted (signed message and transmitted message MUST be identical). Example message: From: Michael Elkins To: Michael Elkins Mime-Version: 1.0 Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5; protocol="application/pgp-signature" @@ -391,21 +377,21 @@ 9. Notes "PGP" and "Pretty Good Privacy" are registered trademarks of Network Associates, Inc. 10. Acknowledgements 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 - 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 ongoing work on PGP; to Charles Breed for originally proposing the formation of the OpenPGP Working Group; and to Steve Schoenfeld for helpful feedback during the draft process. The authors would also like to thank the engineers at Pretty Good Privacy, Inc (now Network Associates, Inc), including Colin Plumb, Hal Finney, Jon Callas, Mark Elrod, Mark Weaver and Lloyd Chambers, for their technical commentary.