--- 1/draft-ietf-openpgp-mime-01.txt 2006-02-05 00:55:22.000000000 +0100 +++ 2/draft-ietf-openpgp-mime-02.txt 2006-02-05 00:55:22.000000000 +0100 @@ -1,19 +1,18 @@ - OpenPGP Working Group M. Elkins -draft-ietf-openpgp-mime-01.txt Network Associates, Inc. +draft-ietf-openpgp-mime-02.txt Network Associates, Inc. Obsoletes: 2015 D. Del Torto CryptoRights Foundation R. Levien University of California at Berkeley T. Roessler - April 2000 + August 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 @@ -34,47 +33,45 @@ Copyright (C) The Internet Society 2000. All Rights Reserved. Abstract This document describes how the OpenPGP Message Format [1] can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC1847 [2]. This draft is being discussed on the "ietf-openpgp" mailing list. To - join the list, send a message to with - the single word "subscribe" in the subject. A web site containing an - archive of the list can be found at . + join the list, send a message to with + the single word "subscribe" in the subject. An archive of the + working group's list is located at . 1. Introduction Work on integrating PGP (Pretty Good Privacy) with MIME [3] - (including the since withdrawn application/pgp content type) prior to - RFC 2015 suffered from a number of problems, the most significant of - which is the inability to recover signed message bodies without + (including the since withdrawn "application/pgp" content type) prior + to RFC 2015 suffered from a number of problems, the most significant + of which is the inability to recover signed message bodies without parsing data structures specific to PGP. RFC 2015 makes use of the elegant solution proposed in RFC1847, which defines security multipart formats for MIME. The security multiparts clearly separate the signed message body from the signature, and have a number of other desirable properties. This document revises RFC 2015 to adopt the integration of PGP and MIME to the needs which emerged during the work on the OpenPGP specification. This document defines three content types for implementing security - and privacy with OpenPGP: application/pgp-encrypted, application/pgp- - signature and application/pgp-keys. + and privacy with OpenPGP: "application/pgp-encrypted", + "application/pgp-signature" and "application/pgp-keys". The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in - RFC 2119. + 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 to extract and use the OpenPGP information in the message. @@ -91,20 +88,27 @@ does not support MIME or 8-bit data and perform conversion to either Quoted-Printable or Base64. This presents serious problems for multipart/signed, in particular, where the signature is invalidated when such an operation occurs. For this reason all data signed according to this protocol MUST be constrained to 7 bits (8-bit data MUST be encoded using either Quoted-Printable or Base64). Note that this also includes the case where a signed object is also encrypted (see section 6). This restriction will increase the likelihood that the signature will be valid upon receipt. + Additionally, if body parts to be signed contain trailing whitespace, + or lines beginning with the five characters "From ", implementations + SHOULD use either Quoted-Printable or Base64 to protect these body + parts against corruption by transport or delivery agents. Applying + this rule also ensures that trailing whitespace in the data encoded + cannot be modified without invalidating the signature. + Data that is ONLY to be encrypted is allowed to contain 8-bit characters and therefore need not be converted to a 7-bit format. Implementor's note: It cannot be stressed enough that applications using this standard follow MIME's suggestion that you "be conservative in what you generate, and liberal in what you accept." In this particular case it means it would be wise for an implementation to accept messages with any content-transfer- encoding, but restrict generation to the 7-bit format required by this memo. This will allow future compatibility in the event the @@ -113,30 +117,29 @@ 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 [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. + The multipart/encrypted MIME body MUST consist of exactly two body + parts, the first with content type "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. The second MIME body part MUST contain the actual encrypted data. It - must be labeled with a content type of "application/octet-stream". + MUST be labeled with a content type of "application/octet-stream". Example message: From: Michael Elkins To: Michael Elkins Mime-Version: 1.0 Content-Type: multipart/encrypted; boundary=foo; protocol="application/pgp-encrypted" --foo @@ -157,86 +160,80 @@ 1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8= =zzaA -----END PGP MESSAGE----- --foo-- 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. + value of "application/pgp-signature" (MUST be quoted). 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-". 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. + The second body MUST contain the OpenPGP digital signature. It MUST + be labeled with a content type of "application/pgp-signature". + + Implementations MUST generate a "signature of a canonical text + document" as defined in [1]. Implementations MAY accept "signatures + of a binary document" as defined in [1] in order to preserve + interoperability with implementations of [6]. + + To encapsulate multiple signatures with possibly different hash + algorithms, the method specified in [8] should be used. When the OpenPGP digital signature is generated: - (1) The data to be signed must first be converted to its content- + (1) The data to be signed MUST first be converted to its content- type specific canonical form. For text/plain, this means conversion to an appropriate character set and conversion of line endings to the canonical sequence. - (2) An appropriate Content-Transfer-Encoding is then applied. In - particular, if any line begins with the string "From", it is - strongly recommended that Quoted-Printable encoding be applied - and that at least one of the characters in the string is encoded - using the hexadecimal coding rule. This is because many mail - transfer agents treat "From " (the word "from" followed - immediately by a space character) as the start of a new message - and thus insert a right angle-bracket (>) in front of any line - beginning with "From" to distinguish this case, invalidating the - signature. In addition, line endings in the encoded data MUST + (2) An appropriate Content-Transfer-Encoding is then applied; see + section 3. In particular, 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 [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 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). + which elects to adhere to the 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" --bar @@ -363,98 +361,105 @@ Content-Type: application/pgp-keys Required parameters: none Optional parameters: none This is the content type which SHOULD be used for relaying public key blocks. 8. Security Considerations - Use of the protocols defined in this document has the same security - considerations as OpenPGP, and is not known to either increase or - decrease the security of messages using it; see [3], [4] for more - information. + Signatures of a canonical text document as defined in [1] ignore + trailing white space in signed material. If data to be signed + contains trailing white space which should not be modified without + user notification, implementations should make sure to protect this + trailing white space by using either the Quoted-Printable, or the + Base64 Content-Transfer-Encoding, as pointed out in section 3 of the + present document. + + See [3], [4] for more information on the security considerations + concerning the underlying protocols. 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 [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. + ongoing work on PGP; to Charles Breed, Jon Callas and Dave Del Torto + 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. Additional thanks are due to Jeff Schiller and Derek Atkins for their continuing support of strong cryptography and PGP freeware at MIT; to Rodney Thayer of Sable Technology; to John Noerenberg, Steve Dorner and Laurence Lundblade of the Eudora team at QUALCOMM, Inc; John - Gilmore, Hugh Daniel and Fred Ringel (at Rivertown) for their timely - critical commentary; and to the international members of the IETF's - OpenPGP mailing list, including William Geiger, Lutz Donnerhacke and - Kazu Yamamoto. The idea to use multipart/mixed with multipart/signed - has been attributed to James Galvin. Finally, our gratitude is due to - the many members of the "Cypherpunks," "Coderpunks" and "PGP-USERS" - mailing lists and the many users of PGP worldwide for helping keep - the path to privacy open. + Gilmore, Hugh Daniel and Fred Ringel (at Rivertown) and Ian Bell (at + Turnpike) for their timely critical commentary; and to the + international members of the IETF's OpenPGP mailing list, including + William Geiger, Lutz Donnerhacke and Kazu Yamamoto. The idea to use + multipart/mixed with multipart/signed has been attributed to James + Galvin. Finally, our gratitude is due to the many members of the + "Cypherpunks," "Coderpunks" and "pgp-users" + mailing lists and the many users + of PGP worldwide for helping keep the path to privacy open. 11. Addresses of the Authors and OpenPGP Working Group Chair The OpenPGP working group can be contacted via the current chair: John W. Noerenberg II Qualcomm, Inc. 5775 Morehouse Dr. San Diego CA 92121 USA Tel: +1 619 658 3510 Email: jwn2@qualcomm.com The principal authors of this draft are: + Dave Del Torto + CryptoRights Foundation + 80 Alviso Street, Mailstop: CRF + San Francisco CA 94127 USA + Tel: +1.415.334.5533, vm: #2 + Email: ddt@cryptorights.org, ddt@openpgp.net + Michael Elkins Network Associates, Inc. 3415 S. Sepulveda Blvd Suite 700 Los Angeles CA 90034 USA Tel: +1.310.737.1623 Fax: +1.310.737.1755 Email: michael_elkins@nai.com - Raph Levien University of California at Berkeley 579 Soda Hall Berkeley CA 94720 USA Tel: +1.510.642.6509 Email: raph@acm.org - Dave Del Torto - CryptoRights Foundation - 80 Alviso Street, Mailstop: CRF - San Francisco CA 94127 USA - Tel: +1.415.334.5533, vm: #2 - Email: ddt@cryptorights.org, ddt@openpgp.net Thomas Roessler Nordstrasse 99 D-53111 Bonn Germany Tel: +49-228-638007 - Email: roessler@guug.de + Email: roessler@does-not-exist.org References [1] Callas, J., Donnerhacke, L., Finney, H., Thayer, R., "OpenPGP Message Format", RFC 2440, November 1998. [2] Galvin, J., Murphy, G., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.