draft-ietf-openpgp-mime-01.txt   draft-ietf-openpgp-mime-02.txt 
OpenPGP Working Group M. Elkins 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 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
April 2000 August 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 1, line 45 skipping to change at page 1, line 44
Copyright (C) The Internet Society 2000. All Rights Reserved. Copyright (C) The Internet Society 2000. All Rights Reserved.
Abstract Abstract
This document describes how the OpenPGP Message Format [1] can be This document describes how the OpenPGP Message Format [1] can be
used to provide privacy and authentication using the Multipurpose used to provide privacy and authentication using the Multipurpose
Internet Mail Extensions (MIME) security content types described in Internet Mail Extensions (MIME) security content types described in
RFC1847 [2]. RFC1847 [2].
This draft is being discussed on the "ietf-openpgp" mailing list. To This draft is being discussed on the "ietf-openpgp" mailing list. To
join the list, send a message to <ietf-openpgp-requeset@imc.org> with join the list, send a message to <ietf-openpgp-request@imc.org> with
the single word "subscribe" in the subject. A web site containing an the single word "subscribe" in the subject. An archive of the
archive of the list can be found at <http://www.imc.org/ietf- working group's list is located at <http://www.imc.org/ietf-openpgp>.
openpgp>.
1. Introduction 1. Introduction
Work on integrating PGP (Pretty Good Privacy) with MIME [3] Work on integrating PGP (Pretty Good Privacy) with MIME [3]
(including the since withdrawn application/pgp content type) prior to (including the since withdrawn "application/pgp" content type) prior
RFC 2015 suffered from a number of problems, the most significant of to RFC 2015 suffered from a number of problems, the most significant
which is the inability to recover signed message bodies without of which is the inability to recover signed message bodies without
parsing data structures specific to PGP. RFC 2015 makes use of the parsing data structures specific to PGP. RFC 2015 makes use of the
elegant solution proposed in RFC1847, which defines security elegant solution proposed in RFC1847, which defines security
multipart formats for MIME. The security multiparts clearly separate multipart formats for MIME. The security multiparts clearly separate
the signed message body from the signature, and have a number of the signed message body from the signature, and have a number of
other desirable properties. This document revises RFC 2015 to adopt other desirable properties. This document revises RFC 2015 to adopt
the integration of PGP and MIME to the needs which emerged during the the integration of PGP and MIME to the needs which emerged during the
work on the OpenPGP specification. work on the OpenPGP specification.
This document defines three content types for implementing security This document defines three content types for implementing security
and privacy with OpenPGP: application/pgp-encrypted, application/pgp- and privacy with OpenPGP: "application/pgp-encrypted",
signature and application/pgp-keys. "application/pgp-signature" and "application/pgp-keys".
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 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 to extract and use the OpenPGP information this document to be able to extract and use the OpenPGP information
in the message. in the message.
skipping to change at page 3, line 8 skipping to change at page 3, line 7
does not support MIME or 8-bit data and perform conversion to either does not support MIME or 8-bit data and perform conversion to either
Quoted-Printable or Base64. This presents serious problems for Quoted-Printable or Base64. This presents serious problems for
multipart/signed, in particular, where the signature is invalidated multipart/signed, in particular, where the signature is invalidated
when such an operation occurs. For this reason all data signed when such an operation occurs. For this reason all data signed
according to this protocol MUST be constrained to 7 bits (8-bit data according to this protocol MUST be constrained to 7 bits (8-bit data
MUST be encoded using either Quoted-Printable or Base64). Note that MUST be encoded using either Quoted-Printable or Base64). Note that
this also includes the case where a signed object is also encrypted this also includes the case where a signed object is also encrypted
(see section 6). This restriction will increase the likelihood that (see section 6). This restriction will increase the likelihood that
the signature will be valid upon receipt. 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 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. characters and therefore need not be converted to a 7-bit format.
Implementor's note: It cannot be stressed enough that applications Implementor's note: It cannot be stressed enough that applications
using this standard follow MIME's suggestion that you "be using this standard follow MIME's suggestion that you "be
conservative in what you generate, and liberal in what you conservative in what you generate, and liberal in what you
accept." In this particular case it means it would be wise for an accept." In this particular case it means it would be wise for an
implementation to accept messages with any content-transfer- implementation to accept messages with any content-transfer-
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
skipping to change at page 3, line 30 skipping to change at page 3, line 36
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 [2], 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 MIME body MUST consist of exactly two body
MIME body part must have a content type of "application/pgp- parts, the first with content type "application/pgp-encrypted". This
encrypted". This body contains the control information. A message body contains the control information. A message complying with this
complying with this standard MUST contain a "Version: 1" field in standard MUST contain a "Version: 1" field in this body. Since the
this body. Since the OpenPGP packet format contains all other OpenPGP packet format contains all other information necessary for
information necessary for decrypting, no other information is decrypting, no other information is required here.
required here.
The second MIME body part MUST contain the actual encrypted data. It 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: 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/encrypted; boundary=foo; Content-Type: multipart/encrypted; boundary=foo;
protocol="application/pgp-encrypted" protocol="application/pgp-encrypted"
--foo --foo
skipping to change at page 4, line 36 skipping to change at page 4, line 36
1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8= 1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
=zzaA =zzaA
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
--foo-- --foo--
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).
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.
The "micalg" parameter for the "application/pgp-signature" protocol The "micalg" parameter for the "application/pgp-signature" protocol
MUST contain exactly one hash-symbol of the format "pgp-<hash- MUST contain exactly one hash-symbol of the format "pgp-<hash-
symbol>", where <hash-symbol> identifies the Message Integrity Check symbol>", where <hash-symbol> identifies the Message Integrity Check
(MIC) algorithm used to generate the signature. Hash-symbols are (MIC) algorithm used to generate the signature. Hash-symbols are
constructed from the text names registered in [1] or according to the constructed from the text names registered in [1] or according to the
mechanism defined in that document by converting the text name to mechanism defined in that document by converting the text name to
lower case and prefixing it with the four characters "pgp-". lower case and prefixing it with the four characters "pgp-".
Currently defined values are "pgp-md5", "pgp-sha1", "pgp- ripemd160", Currently defined values are "pgp-md5", "pgp-sha1", "pgp- ripemd160",
"pgp-md2", "pgp-tiger192", and "pgp-haval-5-160". "pgp-md2", "pgp-tiger192", and "pgp-haval-5-160".
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. It MUST
MUST be labeled with a content type of "application/pgp-signature" if be labeled with a content type of "application/pgp-signature".
there is a single signature, or "multipart/mixed" if there are two or
more signatures. 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: 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 type specific canonical form. For text/plain, this means
conversion to an appropriate character set and conversion of conversion to an appropriate character set and conversion of
line endings to the canonical <CR><LF> sequence. line endings to the canonical <CR><LF> sequence.
(2) An appropriate Content-Transfer-Encoding is then applied. In (2) An appropriate Content-Transfer-Encoding is then applied; see
particular, if any line begins with the string "From", it is section 3. In particular, line endings in the encoded data MUST
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
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 [2], 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 Note: The accepted OpenPGP convention is for signed data to end
with a <CR><LF> sequence. Note that the <CR><LF> sequence with a <CR><LF> sequence. Note that the <CR><LF> sequence
immediately preceding a MIME boundary delimiter line is considered 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 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 the signed data preceding the delimiter line. An implementation
which elects to adhere to OpenPGP convention has to make sure it which elects to adhere to the OpenPGP convention has to make sure
inserts a <CR><LF> pair on the last line of the data to be signed it inserts a <CR><LF> pair on the last line of the data to be
and transmitted (signed message and transmitted message MUST be signed and transmitted (signed message and transmitted message
identical). MUST be 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"
--bar --bar
skipping to change at page 9, line 26 skipping to change at page 9, line 26
Content-Type: application/pgp-keys Content-Type: application/pgp-keys
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
This is the content type which SHOULD be used for relaying public key This is the content type which SHOULD be used for relaying public key
blocks. blocks.
8. Security Considerations 8. Security Considerations
Use of the protocols defined in this document has the same security Signatures of a canonical text document as defined in [1] ignore
considerations as OpenPGP, and is not known to either increase or trailing white space in signed material. If data to be signed
decrease the security of messages using it; see [3], [4] for more contains trailing white space which should not be modified without
information. 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 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 [1]. 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, Jon Callas and Dave Del Torto
formation of the OpenPGP Working Group; and to Steve Schoenfeld for for originally proposing the formation of the OpenPGP Working Group;
helpful feedback during the draft process. The authors would also and to Steve Schoenfeld for helpful feedback during the draft
like to thank the engineers at Pretty Good Privacy, Inc (now Network process. The authors would also like to thank the engineers at Pretty
Associates, Inc), including Colin Plumb, Hal Finney, Jon Callas, Mark Good Privacy, Inc (now Network Associates, Inc), including Colin
Elrod, Mark Weaver and Lloyd Chambers, for their technical Plumb, Hal Finney, Jon Callas, Mark Elrod, Mark Weaver and Lloyd
commentary. Chambers, for their technical commentary.
Additional thanks are due to Jeff Schiller and Derek Atkins for their Additional thanks are due to Jeff Schiller and Derek Atkins for their
continuing support of strong cryptography and PGP freeware at MIT; to continuing support of strong cryptography and PGP freeware at MIT; to
Rodney Thayer of Sable Technology; to John Noerenberg, Steve Dorner Rodney Thayer of Sable Technology; to John Noerenberg, Steve Dorner
and Laurence Lundblade of the Eudora team at QUALCOMM, Inc; John and Laurence Lundblade of the Eudora team at QUALCOMM, Inc; John
Gilmore, Hugh Daniel and Fred Ringel (at Rivertown) for their timely Gilmore, Hugh Daniel and Fred Ringel (at Rivertown) and Ian Bell (at
critical commentary; and to the international members of the IETF's Turnpike) for their timely critical commentary; and to the
OpenPGP mailing list, including William Geiger, Lutz Donnerhacke and international members of the IETF's OpenPGP mailing list, including
Kazu Yamamoto. The idea to use multipart/mixed with multipart/signed William Geiger, Lutz Donnerhacke and Kazu Yamamoto. The idea to use
has been attributed to James Galvin. Finally, our gratitude is due to multipart/mixed with multipart/signed has been attributed to James
the many members of the "Cypherpunks," "Coderpunks" and "PGP-USERS" Galvin. Finally, our gratitude is due to the many members of the
mailing lists and the many users of PGP worldwide for helping keep "Cypherpunks," "Coderpunks" and "pgp-users"
the path to privacy open. <http://cryptorights.org/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 11. Addresses of the Authors and OpenPGP Working Group Chair
The OpenPGP working group can be contacted via the current chair: The OpenPGP working group can be contacted via the current chair:
John W. Noerenberg II John W. Noerenberg II
Qualcomm, Inc. Qualcomm, Inc.
5775 Morehouse Dr. 5775 Morehouse Dr.
San Diego CA 92121 USA San Diego CA 92121 USA
Tel: +1 619 658 3510 Tel: +1 619 658 3510
Email: jwn2@qualcomm.com Email: jwn2@qualcomm.com
The principal authors of this draft are: 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 Michael Elkins
Network Associates, Inc. Network Associates, Inc.
3415 S. Sepulveda Blvd Suite 700 3415 S. Sepulveda Blvd Suite 700
Los Angeles CA 90034 USA Los Angeles CA 90034 USA
Tel: +1.310.737.1623 Tel: +1.310.737.1623
Fax: +1.310.737.1755 Fax: +1.310.737.1755
Email: michael_elkins@nai.com Email: michael_elkins@nai.com
Raph Levien Raph Levien
University of California at Berkeley University of California at Berkeley
579 Soda Hall 579 Soda Hall
Berkeley CA 94720 USA Berkeley CA 94720 USA
Tel: +1.510.642.6509 Tel: +1.510.642.6509
Email: raph@acm.org 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 Thomas Roessler
Nordstrasse 99 Nordstrasse 99
D-53111 Bonn D-53111 Bonn
Germany Germany
Tel: +49-228-638007 Tel: +49-228-638007
Email: roessler@guug.de Email: roessler@does-not-exist.org
References References
[1] Callas, J., Donnerhacke, L., Finney, H., Thayer, R., "OpenPGP [1] Callas, J., Donnerhacke, L., Finney, H., Thayer, R., "OpenPGP
Message Format", RFC 2440, November 1998. Message Format", RFC 2440, November 1998.
[2] Galvin, J., Murphy, G., Crocker, S., and N. Freed, "Security [2] Galvin, J., Murphy, G., Crocker, S., and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, October 1995. RFC 1847, October 1995.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/