draft-ietf-openpgp-mime-05.txt   draft-ietf-openpgp-mime-06.txt 
OpenPGP Working Group M. Elkins Network Working Group M. Elkins
draft-ietf-openpgp-mime-05.txt Network Presence, LLC. draft-ietf-openpgp-mime-06.txt Network Presence, LLC.
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 2001 April 2001
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 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright (C) The Internet Society 2000. All Rights Reserved. Copyright (C) The Internet Society 2001. 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
RFC 1847 [2]. RFC 1847 [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-request@imc.org> with join the list, send a message to <ietf-openpgp-request@imc.org> with
skipping to change at page 3, line 30 skipping to change at page 3, line 33
avoid compatibility problems with PGP implementations which avoid compatibility problems with PGP implementations which
predate the OpenPGP specification. predate the OpenPGP specification.
Note: If any line begins with the string "From", it is strongly Note: If any line begins with the string "From", it is strongly
suggested that either the Quoted-Printable or Base64 MIME encoding suggested that either the Quoted-Printable or Base64 MIME encoding
be applied. If Quoted-Printable is used, at least one of the be applied. If Quoted-Printable is used, at least one of the
characters in the string should be encoded using the hexadecimal characters in the string should be encoded using the hexadecimal
coding rule. This is because many mail transfer and delivery coding rule. This is because many mail transfer and delivery
agents treat "From " (the word "from" followed immediately by a agents treat "From " (the word "from" followed immediately by a
space character) as the start of a new message and thus insert 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" right angle-bracket (>) in front of any line beginning with "From
to distinguish this case, invalidating the signature. " to distinguish this case, 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 trailing whitespace and therefore need not undergo the characters and trailing whitespace and therefore need not undergo the
convertion to a 7bit format, and the stripping of whitespace. convertion to a 7bit format, and the stripping of whitespace.
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-
skipping to change at page 5, line 13 skipping to change at page 5, line 40
--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). value of "application/pgp-signature" (MUST be quoted).
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 identifier>", where <hash-identifier> identifies the Message
(MIC) algorithm used to generate the signature. Hash-symbols are Integrity Check (MIC) algorithm used to generate the signature.
constructed from the text names registered in [1] or according to the Hash-symbols are constructed from the text names registered in [1] or
mechanism defined in that document by converting the text name to according to the mechanism defined in that document by converting the
lower case and prefixing it with the four characters "pgp-". text name to 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. It MUST The second body MUST contain the OpenPGP digital signature. It MUST
be labeled with a content type of "application/pgp-signature". be labeled with a content type of "application/pgp-signature".
Note: Implementations can either generate "signatures of a Note: Implementations can either generate "signatures of a
canonical text document" or "signatures of a binary document", as canonical text document" or "signatures of a binary document", as
defined in [1]. The restrictions on the signed material put forth defined in [1]. The restrictions on the signed material put forth
in section 3 and in this section will make sure that the various in section 3 and in this section will make sure that the various
MIC algorithm variants specified in [1] and [5] will all produce MIC algorithm variants specified in [1] and [5] will all produce
the same result. the same result.
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; see (2) An appropriate Content-Transfer-Encoding is then applied; see
section 3. In particular, line endings in the encoded data MUST section 3. In particular, 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 section 3 of this document, any trailing (4) As described in section 3 of this document, any trailing
whitespace MUST then be removed from the signed material. whitespace MUST then be removed from the signed material.
(4) As described in [2], the digital signature MUST be calculated (5) 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 (6) 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 the OpenPGP convention has to make sure which elects to adhere to the OpenPGP convention has to make sure
it inserts a <CR><LF> pair on the last line of the data to be it inserts a <CR><LF> pair on the last line of the data to be
signed and transmitted (signed message and transmitted message signed and transmitted (signed message and transmitted message
skipping to change at page 12, line 39 skipping to change at page 12, line 39
Security Services", RFC 1848, October 1995. Security Services", RFC 1848, October 1995.
[5] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message [5] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
Exchange Formats", RFC 1991, August 1996. Exchange Formats", RFC 1991, August 1996.
[6] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC [6] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC
2015, October 1996. 2015, October 1996.
[7] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480, [7] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480,
January 1999. January 1999.
[8] Roessler, T., Del Torto, D., Levien, R., "Multiple Signatures
using Security Multiparts", draft-ietf-multsig-00.txt, January
2000.
Full Copyright Notice Full Copyright Notice
Copyright (C) The Internet Society 2001. All Rights Reserved. Copyright (C) The Internet Society 2001. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
 End of changes. 

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