draft-ietf-openpgp-mime-04.txt   draft-ietf-openpgp-mime-05.txt 
OpenPGP Working Group M. Elkins OpenPGP Working Group M. Elkins
draft-ietf-openpgp-mime-04.txt Network Presence, LLC. draft-ietf-openpgp-mime-05.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 February 2001
MIME Security with OpenPGP MIME Security with OpenPGP
Status of this Memo Status of this Memo
skipping to change at page 3, line 7 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, Additionally, implementations MUST make sure that no trailing
implementations SHOULD use either Quoted-Printable or Base64 to whitespace is present after the MIME encoding has been applied.
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. Applications SHOULD ensure that no trailing whitespace is
present after the MIME encoding has been applied.
Note: Trailing white space does not alter the actual contents of a Note: In most cases, trailing whitespace can either be removed, or
Quoted-Printable or Base64 encoded body part, or the meaning of protected by applying an appropriate content-transfer-encoding.
MIME headers. However, the presence of trailing white space may However, special care must be taken when any header lines - either
trigger a compatibility problem which was introduced in [1]: With in MIME entity headers, or in embedded RFC 822 headers - are
traditional implementations of PGP, trailing whitespace was present which only consist of whitespace: Such lines must be
included with signatures of canonical text documents. [1] changes removed entirely, since replacing them by empty lines would turn
this behaviour in an incompatible way, by specifying that trailing them into header delimiters, and change the semantics of the
white space is ignored in signatures of canonical text documents. message. The restrictions on whitespace are necessary in order to
make the hash calculated invariant under the text and binary mode
signature mechanisms provided by OpenPGP [1]. Also, they help to
avoid compatibility problems with PGP implementations which
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 therefore need not be converted to a 7-bit format. characters and trailing whitespace and therefore need not undergo the
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-
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.
skipping to change at page 5, line 29 skipping to change at page 5, line 29
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".
Implementations MUST generate a "signature of a canonical text Note: Implementations can either generate "signatures of a
document" as defined in [1]. Implementations MAY accept "signatures canonical text document" or "signatures of a binary document", as
of a binary document" as defined in [1] in order to preserve defined in [1]. The restrictions on the signed material put forth
interoperability with implementations of [6]. in section 3 and in this section will make sure that the various
MIC algorithm variants specified in [1] and [5] will all produce
the same result.
To encapsulate multiple signatures with possibly different hash To encapsulate multiple signatures with possibly different hash
algorithms, the method specified in [8] should be used. 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.
skipping to change at page 6, line 5 skipping to change at page 6, line 8
(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
whitespace MUST then be removed from the signed material.
(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
skipping to change at page 9, line 8 skipping to change at page 10, line 8
6.2. Combined method 6.2. Combined method
The OpenPGP packet format [1] describes a method for signing and The OpenPGP packet format [1] describes a method for signing and
encrypting data in a single OpenPGP message. This method is allowed encrypting data in a single OpenPGP message. This method is allowed
in order to reduce processing overhead and increase compatibility in order to reduce processing overhead and increase compatibility
with non-MIME implementations of OpenPGP. The resulting data is with non-MIME implementations of OpenPGP. The resulting data is
formatted as a "multipart/encrypted" object as described in Section formatted as a "multipart/encrypted" object as described in Section
4. 4.
Messages which are encrypted and signed in this combined fashion are Messages which are encrypted and signed in this combined fashion are
REQUIRED to follow the same canonicalization rules as for REQUIRED to follow the same canonicalization rules as
multipart/signed objects. multipart/signed objects.
It is explicitly allowed for an agent to decrypt a combined message It is explicitly allowed for an agent to decrypt a combined message
and rewrite it as a multipart/signed object using the signature data and rewrite it as a multipart/signed object using the signature data
embedded in the encrypted version. embedded in the encrypted version.
7. Distribution of OpenPGP public keys 7. Distribution of OpenPGP public keys
Content-Type: application/pgp-keys Content-Type: application/pgp-keys
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
A MIME body part of this content type contains ASCII-armored A MIME body part of this content type contains ASCII-armored
transferable Public Key Packets as defined in [1], section 10.1. transferable Public Key Packets as defined in [1], section 10.1.
8. Security Considerations 8. Security Considerations
Signatures of a canonical text document as defined in [1] ignore Signatures of a canonical text document as defined in [1] ignore
trailing white space in signed material. If data to be signed trailing white space in signed material. Implementations which
contains trailing white space which should not be modified without choose to use signatures of canonical text documents will not be able
user notification, implementations should make sure to protect this to detect the addition of whitespace in transit.
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 See [3], [4] for more information on the security considerations
concerning the underlying protocols. 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
skipping to change at page 10, line 12 skipping to change at page 11, line 9
for originally proposing the formation of the OpenPGP Working Group; for originally proposing the formation of the OpenPGP Working Group;
and to Steve Schoenfeld for helpful feedback during the draft and to Steve Schoenfeld for helpful feedback during the draft
process. The authors would also like to thank the engineers at Pretty process. The authors would also like to thank the engineers at Pretty
Good Privacy, Inc (now Network Associates, Inc), including Colin Good Privacy, Inc (now Network Associates, Inc), including Colin
Plumb, Hal Finney, Jon Callas, Mark Elrod, Mark Weaver and Lloyd Plumb, Hal Finney, Jon Callas, Mark Elrod, Mark Weaver and Lloyd
Chambers, for their technical 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; to Bodo
Gilmore, Hugh Daniel and Fred Ringel (at Rivertown) and Ian Bell (at Moeller for proposing the approach followed with respect to trailing
Turnpike) for their timely critical commentary; and to the whitespace; to John Gilmore, Hugh Daniel and Fred Ringel (at
international members of the IETF's OpenPGP mailing list, including Rivertown) and Ian Bell (at Turnpike) for their timely critical
William Geiger, Lutz Donnerhacke and Kazu Yamamoto. The idea to use commentary; and to the international members of the IETF's OpenPGP
multipart/mixed with multipart/signed has been attributed to James mailing list, including William Geiger, Lutz Donnerhacke and Kazu
Galvin. Finally, our gratitude is due to the many members of the Yamamoto. The idea to use multipart/mixed with multipart/signed has
"Cypherpunks," "Coderpunks" and "pgp-users" been attributed to James Galvin. Finally, our gratitude is due to the
many members of the "Cypherpunks," "Coderpunks" and "pgp-users"
<http://cryptorights.org/pgp-users> mailing lists and the many users <http://cryptorights.org/pgp-users> mailing lists and the many users
of PGP worldwide for helping keep the path to privacy open. 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.
skipping to change at page 11, line 49 skipping to change at page 12, line 46
[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 [8] Roessler, T., Del Torto, D., Levien, R., "Multiple Signatures
using Security Multiparts", draft-ietf-multsig-00.txt, January using Security Multiparts", draft-ietf-multsig-00.txt, January
2000. 2000.
Full Copyright Notice Full Copyright Notice
Copyright (C) The Internet Society 2000. 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
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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