draft-ietf-openpgp-mime-02.txt   draft-ietf-openpgp-mime-03.txt 
OpenPGP Working Group M. Elkins OpenPGP Working Group M. Elkins
draft-ietf-openpgp-mime-02.txt Network Associates, Inc. draft-ietf-openpgp-mime-03.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
August 2000 August 2000
MIME Security with OpenPGP MIME Security with OpenPGP
Status of this Memo Status of this Memo
skipping to change at page 2, line 39 skipping to change at page 2, line 39
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.
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 multi-part 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
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, if body parts to be signed contain trailing whitespace,
or lines beginning with the five characters "From ", implementations implementations SHOULD use either Quoted-Printable or Base64 to
SHOULD use either Quoted-Printable or Base64 to protect these body protect these body parts against corruption by transport or delivery
parts against corruption by transport or delivery agents. Applying agents. Applying this rule also ensures that trailing whitespace in
this rule also ensures that trailing whitespace in the data encoded the data encoded cannot be modified without invalidating the
cannot be modified without invalidating the signature. 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
Quoted-Printable or Base64 encoded body part, or the meaning of
MIME headers. However, the presence of trailing white space may
trigger a compatibility problem which was introduced in [1]: With
traditional implementations of PGP, trailing whitespace was
included with signatures of canonical text documents. [1] changes
this behaviour in an incompatible way, by specifying that trailing
white space is ignored in signatures of canonical text documents.
Note: 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 and
delivery 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.
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
skipping to change at page 9, line 21 skipping to change at page 9, line 21
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
This is the content type which SHOULD be used for relaying public key A MIME body part of this content type contains ASCII-armored
blocks. 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. If data to be signed
contains trailing white space which should not be modified without contains trailing white space which should not be modified without
user notification, implementations should make sure to protect this user notification, implementations should make sure to protect this
trailing white space by using either the Quoted-Printable, or the trailing white space by using either the Quoted-Printable, or the
Base64 Content-Transfer-Encoding, as pointed out in section 3 of the Base64 Content-Transfer-Encoding, as pointed out in section 3 of the
present document. present document.
skipping to change at page 9, line 45 skipping to change at page 9, line 45
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
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 OpenPGP Message Format. The OpenPGP
is currently described in RFC 2440 [1]. message format 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, Jon Callas and Dave Del Torto ongoing work on PGP; to Charles Breed, Jon Callas and Dave Del Torto
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.
 End of changes. 

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