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/