Network Working Group M. Elkins Request for Comments: ???? Trusted Information Systems, Inc. Category: Standards Track R. Levien University of California at Berkeley D. Del Torto Pretty Good Privacy, Inc. April 1997 MIME Security with Pretty Good Privacy (PGP) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This document describes how to use PGP (Pretty Good Privacy) encryption and digital signature functions to protect the privacy of, and provide authentication for, multimedia Internet message exchanges between mail applications complying with the MIME (Multipurpose Internet Mail Extensions) [1] security content types specified in RFC 1847 [2]. 1. Introduction Encryption and authentication services are highly desirable when exchanging compound multimedia messages with multiple binary files (i.e. sound, image and other binary formats) over unsecured public networks. However, when doing so, fundamental difficulties and incompatibiities between (sometimes archaic) Internet transport mechanisms on are often exposed, causing unacceptable interoperability failures. PGP is a very popular software solution for authenticating communications with digital signatures and securing them with public key encryption, however, the PGP message format as defined in RFC 1991 [4] does not easily survive handling by multiple SMTP transport hosts (a difficulty it shares with many other binary formats). In particular, PGP signatures use digital hashes for authentication and non-repudiation, but these signature blocks are by definition invalidated by any modification to the hashed data, and thus many email systems ruin such signatures under normal operation. Previous efforts to integrate PGP and MIME solved some of these problems, but lacked the ability to recover signed message bodies without requiring the parsing of PGP-specific data structures. RFC 2015 builds on the elegant work in RFC 1847 ("Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted" [2]) which solved the problem of encapsulating authentication and privacy services within the MIME framework. This document therefore extends RFC 1847's concept of security multiparts, which separate the signed message and its signature into two separately-manageable parts. By adding a number of other desirable properties, including the ability to include parallel signatures on the same data, PGP/MIME becomes especially useful for applications such as EDI (Electronic Data Interchange). This document defines three new MIME content types for implementing security and privacy with PGP: application/pgp-encrypted application/pgp-signature application/pgp-keys 1.1 Compliance In order for an implementation to fully comply with this specification, it is necessary for it to obey all items labeled as MUST or REQUIRED. 2. PGP Data Formats PGP can generate either ASCII Armor format as described in RFC 1991 [4], or 8-bit Binary output when encrypting data, generating a digital signature or extracting public key data. ASCII Armor is REQUIRED for data transfer when using the PGP message format. This allows those users who do not have the means to interpret the formats described in this document to be able to extract and use the PGP encoded data contained in the message. 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 than the multipart ASCII-Armored PGP format. 3. Content-Transfer-Encoding Restrictions 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 [1]. However, many existing mail gateways will detect if the next hop does not support MIME or 8-bit data and perform conversion to either Quoted-Printable or Base64. This presents serious problems for multipart/signed, in particular, where the signature is invalidated when such an operation occurs. For this reason all data signed according to this protocol MUST be constrained to 7 bits (8-bit data should be encoded using either Quoted-Printable or Base64). Notice that this also includes the case where a signed object is also encrypted (cf. Section 6). This restriction will greatly increase the likelihood that the signature will be valid upon receipt. Data intended ONLY to be encrypted MAY employ 8-bit or Binary content transfer encoding, and need not be converted to a 7-bit format, because the layer of encryption will protect it from being mangled by Internet transport mechanisms. Note: It cannot be stressed enough that applications using this standard should follow MIME's suggestion that you "be conservative in what you generate, and liberal in what you accept." In this particular case, this means it would be wise for an implementation to accept messages with any content transfer encoding, but restrict generation to the 7-bit format required by this document. This will allow compatibility in the event future changes to the Internet's SMTP framework make it more 8-bit friendly. 4. PGP Encrypted Data Before encryption with PGP, the data should be written in canonical MIME format (header fields plus body). PGP encrypted data is denoted by the "multipart/encrypted" content type, described in RFC 1847 [2], and MUST have a "protocol" parameter value of "application/pgp-encrypted". Note that the value of the parameter MUST be enclosed in quotes. The multipart/encrypted MIME body MUST consist of exactly two parts. The content type of the first part must be "application/pgp-encrypted". This part contains the control information, and a message complying with this standard MUST contain a "Version: 1" field in this part. Since the PGP packet format defined in RFC 1991 [4] contains all other information necessary for decryption, no other information is required here. The second part MUST contain the encrypted data. It MUST be labeled with a content type of "application/octet-stream". Example message: From: Dave Del Torto To: Michael Elkins , Raph Levien Mime-Version: 1.0 Content-Type: multipart/encrypted; boundary=0000_001; protocol="application/pgp-encrypted" --0000_001 Content-Type: application/pgp-encrypted Version: 1 --0000_001 Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- Version: PGP 5.0 hQA8A2RuKj5D5x2JAQF+IZWyCVnMTlN1vphXswccMwpkojROmjnFWKVKoGU5oGcY iRnG7cgWT8E8SjaKvwzyhQCMAwOOf2G87SYNAQP/S5OCb3cDwO/C4Cwq9lXmzOJ6 F0uFOBiWVxVssCQ+bc3Z+mhZ+dsoSQ3rOICy86BIVfZbRUv6CwU28GE4+vLrkM5A o9xSk5gEj9Q9X7otUdhpN2ZuEjNk0ky2hzR+2mRyTXk9Y8+i+ki1R8YGcqxr7/jQ ZL79kx5HoNM0ULMRHuKFAIwDocE4X0qvAOUBA/9e0Jnu9P6mWKl0tvQ0uXdfzdr/ dd9HrvDEOB8Fh3OODtecdgOctmlL3Rb82odQKpAimCHGTndwFZLG+0SJFmRwl9y+ rxYVCq82Yb5Ovpl9RG9TkoeVdNuXRfZg1mfUapO7tFDNczN1QukwpCgtZV/S7sq0 0AOWIZEA3KqvjLhreKSeVPV5yfLLjR9TcRDlMdVccVZY+4jp3c66WTsB8g0qtGjE 0hH4sr4NT/2O4Gv6T+eGrYztkNSSjdSONBV08KEoPn5m+Nb4kImxuq5UuNeWolIw XkndpTehYRHw47WUFbRFvewr0iEyzIf5Fn5yHqK3WeSBqpnUSdiEF+i+J/l+6Hmg YwxsuE6VMDF3AYnrS0oNcTrcA64A/Rod/Oi1dxM= =i2WL -----END PGP MESSAGE----- --0000_001-- 5. PGP Signed Data PGP signed messages are denoted by the "multipart/signed" content type, described in RFC 1847 [2], with a "protocol" parameter which MUST have a value of either "application/pgp-signature" or "multipart/mixed" (parameters MUST be quoted). The "application/pgp-signature" protocol is used for a body with a single signature, and the "multipart/mixed" protocol is used for a body with parallel (multiple) signatures. The "micalg" parameter for the "application/pgp-signature" protocol MUST have a value of "pgp-", where identifies the Message Integrity Check (MIC) algorithm used to generate the signature. The currently-defined values for 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. Note: new values may be registered by sending email to . The listing of current values may be obtained by sending email to . The value of the "micalg" parameter for the "multipart/mixed" protocol MUST be a sequence of at least one micalg. If multiple micalgs are used, they MUST be separated by commas (,) and the micalg parameter itself MUST appear within quotation marks (") as specified by RFC 1521 [1]. 5.1 One-pass Processing This document builds on support defined in RFC 1847 [2] for one-pass processing of signed messages using a micalg statement to specify the hashing algorithm at the beginning of the message body. Note: PGP/MIME signatures, as defined in this document, can be both generated and verified in a single pass, even though the signed message data formats specified in RFC 1991 [4] require a minimum of two separate passes for signature generation. 5.2 Format for Multipart/Signed Body The multipart/signed body MUST consist of exactly two parts. The first part MUST be in canonical MIME format and contain ony the data being signed. It MUST include a content header describing the data, consisting of a set of applicable content header fields. The second part MUST contain either a PGP digital signature or a nested multipart/mixed body itself containing any number of parts, each of which MUST contain a digital signature. In either case, it MUST be labeled with a content type identical to the protocol parameter of the enclosing multipart/signed body. For a single PGP digital signature, the content type MUST be "application/pgp-signature". For parallel (multiple) signatures (cf. Section 7), the content type MUST be "multipart/mixed". Digital signature formats other than PGP are allowed, although the content types and encodings of individual non-PGP digital signatures fall outside the scope of this document. When a PGP digital signature is generated: (1) The data to be signed must first be converted to its type-/subtype- specific canonical form. For text/plain, this means conversion to a supported character set and conversion of line endings to the canonical sequence. (2) An appropriate Content-Transfer-Encoding is then applied. In particular, if any line begins with the string "From " (the word "from" followed immediately by a space character), 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 agents treat "From " as the start of a new message and thus insert a right angle-bracket (>) to distinguish this case (invalidating the signature). In addition, each line of the encoded data MUST end with the canonical sequence. (3) MIME content header fields are then added to the body, each ending with the canonical sequence. (4) As described in [1], the digital signature MUST be calculated over both the data to be signed and its content header fields. (5) The signature generated MUST be detached from the signed data so that the process does not alter the signed data in any way. Example message (prepended "$"s below indicate the portion of the data on which the signature was calculated): From: Michael Elkins To: Raph Levien Mime-Version: 1.0 Content-Type: multipart/signed; boundary=0000_011; micalg=pgp-md5; protocol="application/pgp-signature" --0000_011 $ Content-Type: text/plain; charset=iso-8859-1 $ Content-Transfer-Encoding: quoted-printable $ $ =A1Hola Raph! $ $ =46rom here to eternity, my signature is valid, especially when $ an uppercase "F" is the same as "=46" in Quoted-Printable encoding. $ $ Note: in some cases it might be desirable to encode any =20 $ trailing whitespace that occurs on lines in order to ensure =20 $ that the signature is not invalidated when passing a gateway =20 $ that modifies such whitespace (like BITNET). =20 $ $ me --0000_011 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn HOxEa44b+EI= =ndaj -----END PGP SIGNATURE----- --0000_011-- The accepted PGP convention is for signed data to end with a pair: thus, implementations should output, or scan for, the string "--" following signed data. However, this document does not require it, and implementors may unwisely elect not to insert a pair on the last line of the data to be signed. In the resulting ASCII-Armored digital signature block, the Armor Headerline and Armor Tail may read either: -----BEGIN PGP SIGNATURE----- -----END PGP SIGNATURE----- or, -----BEGIN PGP MESSAGE----- -----END PGP MESSAGE----- although the former is strongly recommended for clarity. The latter is allowed only because it is the default form generated (inaccurately) by PGP version 2.x. Upon receipt of a signed message, an agent MUST: (1) Convert line endings to the canonical sequence before the signature is verified. This is necessary since the local mail transport agent might employ a different local end-of-line convention. (2) Pass both the signed data and its associated content header fields, along with the PGP signature, to the signature verification process. 6. Signed Data Enclosed within Encrypted Data It is sometimes desirable to both digitally sign and then encrypt data in a body part to be sent. It is also useful to be able to forward the signed data inside the encrypted body part separately, with the signature arriving intact for verification. This protocol describes two methods for accomplishing these tasks and their rationales. The first method uses RFC 1847 [2] encapsulation to nest a multipart/signed body within another multipart/encrypted body. This is most useful for standard MIME-compliant message forwarding. In fact, this document imposes no restrictions on the multipart nesting of MIME objects, enabling other message manipulations such as forwarding signed sub-parts along separate paths to different recipients. The second method relies on the PGP packet format as defined in RFC 1991 [4] to combine signing and encrypting operations into a single PGP message and placing it into a single multipart/encrypted MIME body, such that a 2.x-compatible implementation of PGP, when presented with such a combined message, may both decrypt and verify the signature as required. This method is most useful for exchanging signed/encrypted messages with recipients having PGP but no MIME-aware agent. Note: it is explicitly allowed for an agent to decrypt such a combined message and transform it syntactically into a multipart/signed body part using the signature data embedded in the encrypted message. 6.1 Signed & Encrypted Data: RFC 1847 Encapsulation In RFC 1847 [2], it is stated that the data should first be signed as a multipart/signature body, then encrypted to form the final multipart/encrypted body, eg., Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; boundary=0000_021 --0000_021 Content-Type: application/pgp-encrypted Version: 1 --0000_021 Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- # Content-Type: multipart/signed; micalg=pgp-md5 # protocol="application/pgp-signature"; boundary=0000_022 # # --0000_022 # Content-Type: text/plain; charset=us-ascii # # This message was first signed, and then encrypted. # # --0000_022 # Content-Type: application/pgp-signature # # -----BEGIN PGP SIGNATURE----- # Version: 2.6.2 # # iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// # jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq # uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn # HOxEa44b+EI= # =ndaj # -----END PGP SIGNATURE----- # # --0000_022-- -----END PGP MESSAGE----- --0000_021-- Note: prepended #'s above indicate the ciphertext block. 6.2 Signed & Encrypted Data: Combined Method The PGP packet format described in RFC 1991 [4] and implemented in version 2.x of PGP describes a method for signing and encrypting data in a single PGP message. This method is allowed in order to reduce processing overhead and increase compatibility with non-MIME implementations of PGP. The resulting data should be formatted as a "multipart/encrypted" object as described in Section 4. Messages which are signed and encrypted in this combined fashion are REQUIRED to follow the same canonicalization rules as for multipart/signed objects, as described in Section 5, paragraph 4. 7. Parallel (Multiple) Signatures This document specifies a useful mechanism whereby multiple principals in different locations and at separate times can sign the same data in a specific body part and then combine the signed data and all of the separate parallel signature blocks into a single multipart body. Note: care should be taken when implementing an agent to provide adequate trust information to users about existing signatures on MIME objects so as to avoid the signing of compromised data. Where multiple signatures are required, the individual signature blocks are assembled into a multipart/mixed body part, which in turn is used as the second part of a multipart/signed body. Each individual signature block associated with the signed data should be capable of serving as a valid stand-alone signature on that data (cf. Section 5). The protocol parameter of the enclosing multipart/signed object MUST, in this case, be "multipart/mixed". In addition, if parallel signatures are computed using different micalgs, the micalg parameter must be a comma-separated list of all micalgs used by the various signatures. The order of the listed micalgs is not significant, but duplicate micalgs are not permitted in the list. Example of parallel (multiple) signatures: From: Dave Del Torto To: Raph Levien Mime-Version: 1.0 Content-Type: multipart/signed; protocol="multipart/mixed"; boundary=0000_031; micalg="pgp-md5, pgp-sha1, rsa-md5" --0000_031 Content-Type: text/plain Hi Raph, Here's some text with parallel (multiple) digital signatures in various formats. dave ______________________________________________________________________ "All email luxuriantly hand-crafted using only the finest ASCII text." --0000_031 Content-Type: multipart/mixed; boundary=0000_032 --0000_032 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 2.6.2 Comment: Hash computed using MD5 micalg. iQCVAwUBM0Iu16HBOF9KrwDlAQGaiQP9EU1YXgMSoNxDAqSmo7UoCE52DuYCfxm7 x8RfRr9+Xz3nPFytSYM2TIWGMeKi1fVr5PhfjdrKvOh9sCq97h6zndZVpGA9x62k mPVn/QY3fz1eOdyJbYvW4ba7WQll5OoA6cqmEb9tWwh4ra4yE8hZMnLS9a0uPpuB 5dpiTTAE/gY= =hD3D -----END PGP SIGNATURE----- --0000_032 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Comment: Hash computed using SHA-1 micalg (FIPS 180-1). iQCVAwUBM0It9qHBOF9KrwDlAQFBaQQAisIzQUgyknT2v729b7MImcUc3ROdRBh6 nwMyAfdewQYCDxqdDWvnD1UWoUjwjA1JNA6qhTXBxs8yPtZdDZaguOG2zWawyat9 Jib556AuSx10psREDC3vNsaJ99MV8SKFF92H53l9w/YhVOA0aMZeNfLE0jJVypkY /so4/7DHhqQ= =/wlj -----END PGP SIGNATURE----- --0000_032 Content-Type: application/x-pkcs7-signature Content-Transfer-Encoding: base64 Comment: Hash computed using S/MIME MD5 micalg. MIAGCSqGSIb3DQEHAqCAMIACAQExDjAMBggqhkiG9w0CBQUAMIAGCSqGSIb3DQEH AQAAoIAwggFCMIHsAhEA3zCza9kfvSSBz9pg8BvsSzANBgkqhkiG9w0BAQIFADAl MSMwIQYJKoZIhvcNAQkBFhRyYXBoQGNzLmJlcmtlbGV5LmVkdTAeFw05NjA0MjUw NDU5MzFaFw05NzA0MjUwNDU5MzFaMCUxIzAhBgkqhkiG9w0BCQEWFHJhcGhAY3Mu YmVya2VsZXkuZWR1MFowCgYEVQgBAQICAggDTAAwSQJCAL/891njomYStLi2Bloj SuqwcWiyyGSI3KpPmlWZxLwDKbYkFO2lk4vaiJkNazAEvbUeK3G7cxvZZrdc0sWF PjLHAgMBAAEwDQYJKoZIhvcNAQECBQADQgB+QXNNJMs2ga84XfrCJCmxDuhGYbzL 9T9uOOjJVW0AdiKRVNhDec83+/wTzimwMm7maRK32HZ9rpzfqccyUQMCgzCCAg8w ggF4AhEAlxfUD1RsKkKLDLGQCDOk3DANBgkqhkiG9w0BAQQFADCBnTERMA8GA1UE BxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMSAwHgYDVQQLExdD bGFzcyAxIEFzc3VyYW5jZSBMZXZlbDEgMB4GA1UECxMXUHVibGljIFBvbGljeSBB dXRob3JpdHkxKzApBgkqhkiG9w0BCQEWHGNsYXNzMS1pbmNpZGVudEB2ZXJpc2ln bi5jb20wHhcNOTYwNzEwMTkzNzQwWhcNOTYwODA5MTkzNzQwWjA4MREwDwYDVQQH EwhJbnRlcm5ldDEjMCEGCSqGSIb3DQEJARYUcmFwaEBjcy5iZXJrZWxleS5lZHUw WjAKBgRVCAEBAgICCANMADBJAkIAv/z3WeOiZhK0uLYGWiNK6rBxaLLIZIjcqk+a VZnEvAMptiQU7aWTi9qImQ1rMAS9tR4rcbtzG9lmt1zSxYU+MscCAwEAATANBgkq hkiG9w0BAQQFAAOBgQDTwkOLpMLVa/O1Hjht5NYon4UXi0KJWlBtnbB8L3fdY1DS 0qW8mH1a0R1Wci1ln+Lbkp0UAdnBKVniV5lMQ9QbwPBOm6t51WI529XtyAfOh1jB boKeh596OiW1KvME8XzZYhDeUCXaHvU9h04dvYC5kURtiv1y3E0TQN2fpCkZKjCC AlkwggHCAgUCcgAAATANBgkqhkiG9w0BAQIFADBIMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xIDAeBgNVBAsTF0NsYXNzIDEgQXNzdXJhbmNl IExldmVsMB4XDTk1MTIwNzAwMDAwMFoXDTk5MTIzMTIzNTk1OVowgZ0xETAPBgNV BAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEgMB4GA1UECxMX Q2xhc3MgMSBBc3N1cmFuY2UgTGV2ZWwxIDAeBgNVBAsTF1B1YmxpYyBQb2xpY3kg QXV0aG9yaXR5MSswKQYJKoZIhvcNAQkBFhxjbGFzczEtaW5jaWRlbnRAdmVyaXNp Z24uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDgeHrgXvkvVB1tR47O HIdk+rxL1rAi4LR4RKd59okkrOpFdYzwbAUWA7jBphpSD7xSsBUxiOjp5YYhRDL5 zExACvdiIEDJxPqwUvmkmNXYALKaGYWvJWsxALtk0Bpf82y0uxSmUrsdHirSGpaF leH3D2AiEsYMChQ7kpBW1vs5LQIDAQABMA0GCSqGSIb3DQEBAgUAA4GBAKROBq7w k4Ynx1DXItt4EwC6/c6RcnU2RtpE6/uxsgtYFtaPoSUqtl/3kjovWUFEDRe+DBu6 Ae3Vm3x3kklF9b9Dq9+IUIurDTqtx30bYTcuDdfNu3V8cz9/CFNeUAHb+RAremus 3s/msgDvuyo9NyzkSWUlPjsqolRPs1S9/yC4AAAxgDCCARkCAQEwgbMwgZ0xETAP BgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEgMB4GA1UE CxMXQ2xhc3MgMSBBc3N1cmFuY2UgTGV2ZWwxIDAeBgNVBAsTF1B1YmxpYyBQb2xp Y3kgQXV0aG9yaXR5MSswKQYJKoZIhvcNAQkBFhxjbGFzczEtaW5jaWRlbnRAdmVy aXNpZ24uY29tAhEAlxfUD1RsKkKLDLGQCDOk3DAMBggqhkiG9w0CBQUAMA0GCSqG SIb3DQEBAQUABEFLIdfhsiaOxHtsC6zBX/JR7S6rLcP9IlPKKYINvXtLvaEzxFJ7 +kNIWIbxNiNje1wlzIhaGjrGrOnvYc8+tFn2LgAAAAAAAAAA --0000_032-- --0000_031-- 8. Distribution of PGP Public Keys This document defines a new content type for transporting PGP public keys in RFC 1991 format [4]. Before transport, the public key block is first ASCII-Armored, then MIME-encapsulated with the content type "application/pgp-keys". No required or optional parameters are specified by this document. The resulting object may appear in various MIME-compliant contexts, including (1) an individual message body, (2) within an enclosing multipart, or (3) protected within a multipart/encrypted or multipart/signed body part. Agents should be prepared to accept public key blocks which are nested, perhaps even two or three levels deep, inside multipart bodies. When processing any application/pgp-keys body, the recommended agent behavior is to alert the user to the presence of the encapsulated keys and offer her an informed choice for how to further process the key material. If the agent can determine automatically whether the key is trusted, it may be processed silently, based on predetermined user preferences. Agent or user preferences may also specify other cases where keys are to be processed fully automatically, as in EDI applications. Note: RFC 1991 [4] created a usabilty problem by specifying that an extra hyphen and space be prepended to the Armor Headerline and Armor Tail of any public key blocks enclosed within a clearsigned message. This prevented clearsigned keys from being easily recognized when such messages were parsed directly. However, as a happy consequence of MIME-encapsulation, the mechanisms described in this document preserve the integrity of all included parts, including PGP public keys, thus simplifying the processing of PGP public key blocks for both implementors and users. 9. Legal Considerations "PGP" and "Pretty Good Privacy" are registered trademarks of Pretty Good Privacy, Inc. 10. Security Considerations Use of this protocol has the same security considerations as PGP, and is not otherwise known to either increase or decrease the security of messages employing it; see RFC 1991 [4] for further information. 11. Author's Addresses Michael Elkins Trusted Information Systems, Inc. P.O. Box 92957 - M1/102 Los Angeles CA 90009-2957 USA Phone: +1.310.336.8040 Fax: +1.310.336.4402 Email: michael@tis.com Raph Levien University of California at Berkeley 579 Soda Hall Berkeley CA 94720 USA Phone: +1.510.642.6509 Email: raph@acm.org Dave Del Torto Pretty Good Privacy, Inc. 2121 El Camino Real San Mateo CA 94403 USA Phone: +1.415.596.1781 Fax: +1.415.631.1033 Email: ddt@pgp.com References [1] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies," RFC 1521, Bellcore and Innosoft, September 1993. [2] Galvin, J., Murphy, G., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [3] Galvin, J., Murphy, G., Crocker, S., and N. Freed, "MIME Object Security Services", RFC 1848, October 1995. [4] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996. [5] FIPS PUB 180-1 "Secure Hash Standard", Federal Information Processing Standards Publication, U.S. Department of Commerce, National Institute of Standards and Technology/Computer Systems Laboratory, April 1995.