Network Working Group S. Dusse INTERNET DRAFT RSA Data Security, Inc. Category: Internet-Draft SEPTEMBER, 1996 Expire in six months S/MIME Message Specification: PKCS Security Services for MIME Status of this Memo: This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. To learn the current status of any Internet-Draft, please check lid- abstract.txt listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a standard way to send and receive secure electronic mail. Based on the popular Internet MIME standard (RFC 1521), S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures) and privacy and data security (using encryption). 1.0 Overview This document describes a protocol for adding cryptographic signature and encryption services to Internet MIME messages. The Internet MIME standard (RFC 1521), provides a general structure for the content type of Internet mail messages and allows extensions for new content type applications. Therefore, this draft defines application/x-pkcs7-mime which specifies that a MIME body part has been cryptographically enhanced according to PKCS #7. This draft also defines application/x-pkcs10 for use in submitting a certification request. This document discusses the use of multipart/signed and application/x-pkcs7-signature, which can be used to display the "clear text" of a signed message for the benefit of readers using an e-mail system with no security services. Dusse [2] INTERNET DRAFT S/MIME Messaging Specification September, 1996 This specification is compatible with PKCS #7 in that it uses the data types defined by PKCS #7. It also inherits all the varieties of architectures for certificate-based key management supported by PKCS #7. PKCS #7 describes binary encodings that can be transmitted over 7-bit electronic mail systems. MIME solves that problem by using its content transfer encoding services. 1.2 Definitions For the purposes of this draft, the following definitions apply. ASN.1: Abstract Syntax Notation One, as defined in C.C.I.T.T. X.208. BER: Basic Encoding Rules for ASN.1, as defined in C.C.I.T.T. X.209. Certificate: A type that binds an entity's distinguished name to a public key with a digital signature. This type is defined in C.C.I.T.T. X.509. This type also contains the distinguished name of the certificate issuer (the signer), an issuer-specific serial number, the issuer's signature algorithm identifier, and a validity period. CertificateRevocationList (CRL): A type that contains information about certificates whose validity an issuer has prematurely revoked. The information consists of an issuer name, the time of issue, the next scheduled time of issue, and a list of certificate serial numbers and their associated revocation times. The CRL is signed by the issuer. The type intended by this standard is the one defined in RFC 1422. DER: Distinguished Encoding Rules for ASN.1, as defined in C.C.I.T.T. X.509, Section 8.7. MIME: Multipurpose Internet Mail Extensions, as defined in RFC 1521. Data Types: These definitions are those used with the MIME and SMTP standards. 7-bit: Text data with lines less than 998 characters long, documents of the Internet Engineering Task Force (IETF), its areas, and characters with the 8th bit set and no NULL characters. and occur only as part of a end of line delimiter. 8-bit: Text data with lines less than 998 characters, and no NULL characters. and occur only as part of a end of line delimiter. binary: Arbitrary data. Transfer Encoding: A reversible transformation made on data so 8-bit or binary data may be sent via a channel that only transmits 7-bit data. Dusse Page [2] Dusse [3] INTERNET DRAFT S/MIME Messaging Specification September, 1996 2.0 Content-Type application/x-pkcs7-mime This section defines the format of data used in application/ x-pkcs7-mime. First we introduce the data format and discuss various implementation issues. Then we describe the steps an agent must follow to send or receive an application/x-pkcs7-mime body part. Finally, we discuss some security considerations. 2.1 Format of the application/x-pkcs7-mime body PKCS #7 defines a general ASN.1 type, ContentInfo, for use in exchanging cryptographic information. For convenience, its definition is repeated here: ContentInfo ::= SEQUENCE { contentType ContentType, content[0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } ContentType ::= OBJECT IDENTIFIER PKCS #7 also defines several content types which can be used within a ContentInfo. For our purposes here, the most important are SignedData (for exchanging digitally signed data), EnvelopedData (for exchanging digitally enveloped data) and SignedAndEnvelopedData (for exchanging data both digitally signed and enveloped). Therefore, when the MIME content type application/x-pkcs7-mime is used, the body shall be a ContentInfo as defined by PKCS #7, encoded using the Basic Encoding Rules (BER). The PKCS #7 content type will normally be SignedData, EnvelopedData or SignedAndEnvelopedData, but use of other content types defined by PKCS #7 are not disallowed. 2.1.1 Notes Since BER is specified, instead of the more restrictive DER, an application may use techniques such as indefinite-length encoding. This is especially useful for transferring large data or streamed data where the total length is not known in advance. Data produced by BER is 8-bit, but many transports are limited to 7-bit data. Therefore, in most situations, a suitable 7-bit Content-Transfer-Encoding is needed, such as base64. This is discussed in a later section. PKCS #7 has a provision for "detached data", where, for example, the SignedData in the ContentInfo contains only the signature information, but not the actual data which is signed (which is transferred separately). Application/x-pkcs7-mime explicitly disallows the use of detached data and requires the data to be present within the ContentInfo. The "detached data" provision is, however, used by the multipart/signed construct described in Section 6. Dusse Page [3] Dusse [4] INTERNET DRAFT S/MIME Messaging Specification September, 1996 PKCS #7 provides for a degenerate case of SignedData which can be used for disseminating certificates and CRLs. This is explicitly allowed in application/x-pkcs7-mime. In this case, the content is omitted from the ContentInfo and there are no entries in the SignerInfos, leaving only entries for certificates and crls. Typically, this is used to convey certificates in response to a certification request, or CRLs in response to a CRL retrieval request. The MIME agent should process and/or store the certificates and CRLs and may choose to display a confirmation to the user. 2.2 Format of the signed or enveloped data PKCS #7 places no requirements on the format of the data which is signed or enveloped. However, for use in application/x-pkcs7-mime, the signed or enveloped data must itself be a MIME entity. Therefore, when a MIME agent receives an application/x-pkcs7-mime, the result of removing the signature or envelope can be passed directly to the normal MIME-processing software. Because the MIME entity being signed or enveloped is likely to be transferred to and processed on a different platform than it was created it is important that it be in canonical or "on-the-wire" format. The most common difference between platforms is the end of line delimiter. In addition to being in canonical MIME format there are some considerations for the selection of the transfer encoding for the MIME entity that affect the ability to verify the signature of a received MIME entity, especially if it is to be subsequently forwarded. Since the data which is signed or enveloped must be recovered by the recipient in the exact form it was produced by the sender, we must take care that this data be in a canonical format which can be processed by any platform. A rough outline of what is needed to convert a MIME entity into canonical format is given here, but the implementor is referred to the MIME RFCs for complete details. It is also advisable to check for IETF drafts of the MIME specification that are later than the most recent RFCs until MIME is published as a complete IETF standard. This following set of steps is prescriptive to illustrate exactly what the end result must be. An implementation need not perform these steps exactly as long as the end result is the same as if the steps were performed. Given that the data objects to be included in the message are available in the local format, the first step is to convert each object to its canonical format. The canonical format of each object is determined by its MIME type and subtype as it is tagged in the MIME entity. For example, data of MIME type text/plain must have each end of line delimiter converted to , and an isolated or is not permitted. Another canonicalization that may be required is the conversion from the local character set to a standard character set. Many data types such as image/gif or application/postscript have only one format and this serves as both the canonical format and the local format no matter the platform. Dusse Page [4] Dusse [5] INTERNET DRAFT S/MIME Messaging Specification September, 1996 The second step is the application of transfer encoding. Transfer encoding is used to transform 8-bit text (e.g., in the ISO-8859-1 character set) or binary data (arbitrary line length, may include any octet including NULL) in such a way that it can be transmitted over 7-bit or non-binary channels. Note that when transfer encoding is applied in this step the output lines of the transfer encoder will be lines of 7-bit text with canonical line ending. Any transfer encoding to the MIME entity inside the PKCS envelope will be referred to as the "inside transfer encoding." Strictly speaking no transfer encoding is required for a MIME object inside the PKCS envelope since it will be embedded in a PKCS object which is effectively a binary channel, but there are some further considerations. If the PKCS envelope is ever removed and the resulting MIME object is ever to be transmitted by itself without further processing via standard SMTP transport it is advisable to use some transfer encoding. The choice is at the discretion of the implementor. If no Content-Transfer-Encoding header is included, it is assumed that the transfer encoding is 7-bit and that the data will be conformant. If the data is binary, then a Content-Transfer-Encoding: binary header must be included. The same is true for 8-bit data. Third, the encoded sub-entities are inserted in the full MIME entity. This step consists essentially of concatenating the sub-entities interspersed with the appropriate MIME Content-type, Content-Transfer- Encoding and related headers and part boundaries. Note that MIME headers and boundaries are all text with canonical line endings. 2.2.1 Notes The requirement that the signed or enveloped data must itself be a MIME body part is why the protocol defined here is called application/x-pkcs7-mime and not just application/x-pkcs7. A protocol for transferring a PKCS #7 object with arbitrary signed or enveloped content could be defined, but is outside the scope of this document. 2.3 Outside Content transfer encoding The body of application/x-pkcs7-mime is a BER-encoded PKCS #7 ContentInfo. However, as mentioned above, the result of BER-encoding is binary data, not 7-bit text as required by most SMTP mail transport agents. In general, base64 Content-Transfer-Encoding can be used, though all that is required is that the transfer encoding be such that application/x-pkcs7-mime entity can be transferred intact. (It is even possible that the transfer encoding will be changed by the message transfer agent, as this is explicitly permitted.) 2.4 Sending an application/x-pkcs7-mime body part Now that we have introduced the various formats and issues, we can describe the steps for sending a message using application/x-pkcs7-mime. In this example, we create a digital envelope, but the same process applies to other PKCS #7 content types. Dusse Page [5] Dusse [6] INTERNET DRAFT S/MIME Messaging Specification September, 1996 Note that the first four steps listed here are the steps for preparing a MIME entity for transmission via SMTP with the exception that binary transfer encoding is allowed. The implementor is referred to the MIME conformance document for the precise details. Also, these steps need not be performed exactly as described here as long as the result obtained is identical. Each message part is prepared as usual by the message composition software and becomes available in its local format. Each message part is converted to its canonical format as defined for its MIME content type (e.g., end of line delimiters are converted to for type text/plain). If desired by the implementor, transfer encoding is applied to each message part. It is optional as the default inside transfer encoding for message parts is binary. If the data for a MIME part is not 7-bit data, then a Content-Transfer-Encoding header indicating whether it is either 8-bit or binary must be inserted as part of the following step. MIME Content-xxxx headers are added to each part, and if there are multiple parts each entity is inserted into a multipart message. That is, the message parts are assembled into a complete MIME entity. The MIME entity is encrypted according to PKCS #7 EnvelopedData, where the encrypted message is placed in the EnvelopedData's EncryptedContentInfo. (Note that the EnvelopedData also contains the RecipientInfo data which the recipient will use to open the envelope and decrypt the message.) * The EnvelopedData is placed within a PKCS #7 ContentInfo. * The ContentInfo is encoded according to BER. As a typical step, the BER-encoded ContentInfo is also base64 encoded so that it is 7-bit data suitable for mail transfer agents. This then becomes the body of an application/x-pkcs7-mime body part. The result might look like this: Content-Type: application/x-pkcs7-mime Content-Transfer-Encoding: base64 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 2.5 Receiving an application/x-pkcs7-mime body part These are the steps for receiving the application/x-pkcs7-mime message from the previous example. * Any content transfer encoding is removed, which in this example is base64. * The PKCS #7 ContentInfo is examined to determine the PKCS #7 content type, which in this case is EnvelopedData. Dusse Page [6] Dusse [7] INTERNET DRAFT S/MIME Messaging Specification September, 1996 * The RecipientInfoEnvelopedData is processed in order to decrypt the content, which must be a MIME body part as required by application/x-pkcs7-mime. * The result is passed to a standard MIME processor which removes transfer encoding, splits multipart entities, and possibly converts the parts to local format. In this example, the message "This is an encrypted message" is displayed to the user. 3.0 Content-Type application/x-pkcs10 A typical application which allows a user to generate cryptographic information must submit that information to a certification authority, who transforms it into a certificate. PKCS #10 describes a syntax for certification requests. We therefore define application/x-pkcs10 which can be used to transfer a PKCS #10 certification request. The details of certification requests and the process of obtaining a certificate are beyond the scope of this document. Here, we only define the format of data used in application/x-pkcs10. First we introduce the data format and discuss various implementation issues. Then we describe the steps an agent must follow to send or receive an application/x-pkcs10 body part. 3.1 Format of the application/x-pkcs10 body PKCS #10 defines the ASN.1 type CertificationRequest for use in submitting a certification request. Therefore, when the MIME content type application/x-pkcs10 is used, the body shall be a CertificationRequest, encoded using the Basic Encoding Rules (BER). Although BER is specified, instead of the more restrictive DER, a typical application will use DER since the CertificationRequest's CertificationRequestInfo must be DER-encoded anyway in order to be signed. A robust application should output DER, but allow BER or DER on input. Data produced by BER or DER is 8-bit, but many transports are limited to 7-bit data. Therefore, a suitable 7-bit Content-Transfer-Encoding is needed. This document recommends using the base64 Content-Transfer-Encoding with application/x-pkcs10, although any 7-bit transfer encoding will work. 3.2 Sending and receiving an application/x-pkcs10 body part Now that we have introduced the various formats and issues, we can describe the steps for sending a message using application/x-pkcs10. The application generates the cryptographic information for the user. The details of this are beyond the scope of this document. * The cryptographic information is placed within a PKCS #10 CertificationRequest. Dusse Page [7] Dusse [8] INTERNET DRAFT S/MIME Messaging Specification September, 1996 * The CertificationRequest is encoded according to BER or DER (typically, DER). * As a typical step, the DER-encoded CertificationRequest is also base64 encoded so that it is 7-bit data suitable for mail transfer agents. This then becomes the body of an application/x-pkcs10 body part. The result might look like this: Content-Type: application/x-pkcs10 Content-Transfer-Encoding: base64 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V A typical application only needs to send a certification request. It is a certification authority which must receive and process the request. The steps for recovering the CertificationRequest from the message are straightforward and are not presented here. The procedures for processing the certification request are beyond the scope of this document. 4.0 Use of the Multipart/Signed Content-Type RFC 1847 defines the multipart/signed content type explicitly for clear-signed messages. Clear signing means the content is in the clear so that recipients with older e-mail systems that cannot process PKCS information can still read the message even if they cannot verify the signature. The multipart/signed MIME type is a multipart type with exactly two parts. The first part carries the MIME entity being signed. The second part carries the signature. The multipart/signed Content type has the following parameters: * The protocol parameter (required): "application/x-pkcs7- signature" * The micalg parameter: rsa-md5 Note that quoting is required around the protocol parameter as a "/" character in a parameter value must be quoted. The micalg parameter allows for one-pass processing when the signature is being verified. The value of the micalg parameter is dependent on the message digest algorithm used in the calculation of the Message Integrity Check, rsa-md5 is included as an example. This specification does not require or recommend any particular choice of mic algorithm. 4.1 Preparation of the data for signing The data is prepared as described in section 2 with the following extra considerations for transfer encoding. All parts of the MIME entity must have transfer encoding of 7-bit, quoted-printable, or base64. No binary or 8-bit data is permitted. This is required because Dusse Page [8] Dusse [9] INTERNET DRAFT S/MIME Messaging Specification September, 1996 the current Internet mail transport infrastructure cannot guarantee transport of unencoded binary or 8-bit data and because the digest for the signature is computed on the fully encoded message. If a message with 8-bit data were to encounter a transfer agent that can not transmit 8-bit or binary data it has three options, none of which are acceptable for a clear-signed message. First, it could change the transfer encoding, but that would invalidate the signature. It could transmit anyway which would most likely result in the 8th bit being stripped, also resulting in the signature being invalidated. Last it could return the message to the sender. Thus transfer encoding to make the data 7-bit text is required before computing the signature. Note RFC 1847 prohibits an MTA from changing the transfer encoding of the first part of a multipart/signed message. If a compliant MTA encountered a multipart/signed message with 8-bit or binary data in the first part, it would have to return the message to the sender as undeliverable. Note that is it is advisable to use quoted printable transfer encoding in some situations that may not otherwise seem necessary to better preserve the data so the signature can be verified. For example, trailing spaces should always be quoted-printable encoded as some mail systems strip them if they are not transferred with encoding. Also the word "From" followed by a space at the beginning of a line should be encoded as some mail systems convert this to ">From". Because of the restriction on 8-bit transport it is also necessary to use quoted printable encoding for text using an 8-bit character set such as ISO- 8859-1. 4.2 The application/x-pkcs7-signature type The second part of the multipart/signed message must have type application/x pkcs7-signature. The data in the second part is the PKCS #7 detached signature. A detached signature is a PKCS #7 data object of type SignedData with the signerInfos field containing signatures on some external data and the ContentInfo field empty. In this case the external data is the fully encoded MIME entity described above and placed in the first part of the multipart/signed message. 4.3 Procedure for sending a clear signed message The data is prepared as described above so the transfer encoding of all the parts is either 7-bit, quoted-printable or base64. The PKCS #7 detached signature for the data is computed. The content data is inserted into the first part of the multipart/signed MIME entity. The detached signature is inserted into the second part of the multipart/signed message using appropriate transfer encoding (most likely base64). The MIME type of the detached signature part must be application/x-pkcs7-signature. 4.4 Procedure for receiving a clear signed message The message digest of the first part of the multipart/signed message Dusse Page [9] Dusse [10] INTERNET DRAFT S/MIME Messaging Specification September, 1996 is computed before any further MIME decoding or processing other than separating the two parts of the multipart/signed entity. The application/x-pkcs7-signature information in the second part is processed along with the digest obtained in the first step to verify the signature. The MIME processing and decoding of the first part proceeds and the message is presented to the user along with the result of the signature verification. Example multipart/signed message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=rsa-md5; boundary=boundary42 --boundary42 Content-Type: text/plain This is a clear-signed message --boundary42 Content-Type: application/x-pkcs7-signature Content-Transfer-Encoding: base64 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42-- 5.0 Security considerations All of the security issues faced by any cryptographic application must be faced by a MIME agent which supports application/x-pkcs7-mime. Among these are protecting the user's private key, preventing various attacks, and helping the user avoid mistakes such as inadvertently encrypting a message for the wrong recipient. These issues are beyond the scope of this document, however we can make the following notes: An implementor may choose not to present data which has been digitally signed if the signature verification fails. The reasoning is that if the signature fails, the data very likely has been tampered with and should be considered untrustworthy. This is consistent with the fact that the signed data within an application/x-pkcs7-mime entity cannot be seen by viewing the "raw" MIME message, since it is base64 encoded (unless is it sent clear signed as described in section 6). The message must be processed and the signature verified before the data is presented. If the implementor does choose to present the data even if the signature verification fails, it is advisable to strongly warn the user. A MIME agent which supports application/x-pkcs7-mime inherits the Dusse Page [10] Dusse [11] INTERNET DRAFT S/MIME Messaging Specification September, 1996 certificate-based key management supported by PKCS #7. In particular, a typical agent must be able to process certificates and CRLs which may be included inside a SignedData or SignedAndEnvelopedData type. The agent may also include auxiliary services to allow the user to generate keys, submit and process certification requests and to request updated CRLs. 6.0 References RFC 1521 N. Borenstein, N. Freed. RFC 1521: MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. September 1993. PKCS #7 RSA Laboratories. PKCS #7: Cryptographic Message Syntax Standard. Version 1.5, November 1993. PKCS #10 RSA Laboratories. PKCS #10: Certification Request Syntax Standard. Version 1.0, November 1993. RFC 1847 J. Galvin, S.Murphy, S. Crocker, N. Freed. RFC 1847 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. October 1995. [Conformance] N Freed. IETF draft-ietd-822ext-mime-conf-XX.txt. Multipart Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples. September 1995. 7.0 Acknowledgements The S/MIME Message specification is the result of numerous interactions and gatherings between RSA and various email vendors. Significant contributions were made by Jeff Thompson, author of RIPEM and Lawrence Lundblade. 8.0 Author's Address Steve Dusse RSA Data Security, Inc 100 Marine Parkway, Suite 500 Redwood City, CA. 94065 Phone: 415-595-8782 Fax: 415-595-1873 Email: Steve@rsa.com Dusse Page [11]