Network Working Group Steve Crocker INTERNET DRAFT Ned Freed draft-ietf-pem-mime-05.txt Jim Galvin Sandy Murphy June 1994 PEM Security Services and MIME 1. 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 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 the 1id-abstracts.txt listing contained in one of the Internet Drafts Shadow Directories on ds.internic.net (US East Coast), venera.isi.edu (US West Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe). 2. Abstract This document specifies how the services of MIME and PEM can be used in a complementary fashion. MIME, an acronym for "Multipurpose Internet Mail Extensions", defines the format of the contents of Internet mail messages and provides for multi-part textual and non-textual message bodies. PEM, an acronym for "Privacy Enhanced Mail", provides message authentication/integrity and message encryption services for Internet mail messages. An Internet electronic mail message consists of two parts: the headers and the body. The headers form a collection of field/value pairs structured according to RFC 822 [1], whilst the body, if structured, is defined according to MIME [2]. MIME does not provide for the application of security services. Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 1]
INTERNET DRAFT PEM and MIME June 1994 PEM [3-6] specifies how to apply encryption and authentication/integrity services to the contents of a textual electronic mail message but does not provide message structuring or type labelling facilities. This document specifies how to use PEM with the multipart/signed and multipart/encrypted MIME content types to provide authentication/integrity and encryption services. We refer to the authentication/integrity service as a digital signature service. This document updates the message encryption and signature procedures defined by [3] and obsoletes the key certification and related services defined by [6]. The changes to [3] include the separation of the encryption and signature services, the removal of the limitation to enhance only text-based messages, the removal of the transfer encoding operation, the deprecation of the Content-Domain: and Proc-Type: headers, and the separation of certificate and certificate revocation list transmission from the security enhancements. These changes represent a departure in mechanism, not in effect, and are detailed in Section ??. In addition, this document proposes three technical changes: in [3] symmetric key management is deprecated, also in [3] the canonicalization operation is generalized, and in [4] the allowable name forms for the subjects of certificates is broadened to include arbitrary strings and email addresses, and users may distribute their public keys directly in lieu of certificates. The key certification and related services document [6] is obsoleted by the specification of two new MIME content types: application/key-request and application/key-data. These new content types are used to transmit requests for key operations (retrieval, certification, revocation list retrieval, etc.) and the responses to those requests. These two content types are independent body parts and are not required to be encapsulated in any other body part. These changes represent a departure in mechanism, not in effect, and are detailed in Section ??. The relationship between MIME and PEM is described in terms of two functions: message composition and message delivery. 3. Applying PEM Security Services to MIME Body Parts The next section describes the processing steps necessary to prepare a MIME body part for the application of PEM security services. The succeeding two sections describe the content of the multipart/signed and multipart/encrypted body parts resulting from the application of PEM security services to MIME body parts. Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 2]
INTERNET DRAFT PEM and MIME June 1994 3.1. PEM Processing Steps The following three steps describe the preparation of outbound PEM messages. These steps may be repeated as necessary to prepare a message for submission. (1) Local Form -- the content of the message is prepared in the native format of the user's local environment (2) Canonical Form -- the content of the message is transformed to a canonical form for the digital signature service; no canonicalization is required for the encryption service (3) Security Form -- either of the signature or encryption services may be applied Each of these steps is described in detail below. Their relationship to message composition and delivery is described in Section ??. 3.1.1. Step 1: Local Form The message content is created in the native format of the user's local environment. 3.1.2. Step 2: Canonical Form Prior to the application of the digital signature service, the content must be in a canonical form. No canonicalization is required for the encryption service and therefore processing continues with the next step. Transforming the content to be signed into a canonical form is a necessary and essential step in the digital signature process. The canonical form must satisfy the property that it is uniquely and unambiguously representable on both the originator and recipient's local environment. This is required in order to ensure that both the originator and recipient have the same data with which to calculate the digital signature; the originator needs to be able to include the digital signature value when transferring the body part, while the recipient needs to be able to compare a re-calculated value with the received value. Further, the canonical form should satisfy the property that it is representable on as many different host computers as possible. By satisfying this property, signed data may be forwarded by recipients to additional recipients, who will also be able to verify the original signature. This service is called forwardable authentication. Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 3]
INTERNET DRAFT PEM and MIME June 1994 The canonical form of all content types is defined to be 7bit. The data to be signed must be represented as 7bit. Since the MIME standard explicitly disallows nested encodings, the body parts enclosed in a multipart content type, for example, must be encoded in a 7bit representation. Any valid MIME encoding may be selected. The 7bit representation of the data is transferred to the recipient. As may be required by MIME, an appropriate Content-Transfer-Encoding: header is included with the data. Upon receipt, a MIME implementation would verify the signature of the data prior to decoding the data and displaying it to the recipient. Representing all complex content types as 7bit transforms them into text-based content types. However, text-based content types present a unique problem. In particular, there are far too many broken message transfer agents that make arbitrary changes to text-based messages as they are relayed, including adding, deleting, or changing TAB and SPACE characters, and line delimiters are altered by message transfer agent protocols. These changes will make it impossible for recipients to verify the signature on a message. The application of the digital signature service requires that the same line delimiter be used by both the originator and the recipient. This document specifies that the two character sequence "<CR><LF>" must be used as the line delimiter. Thus, the canonicalization transformation is to transform the local line delimiter to the two character sequence "<CR><LF>". The transformation to the universal line delimiter is only required for the purposes of computing the digital signature. Thus, originators must apply the universal line delimiter transformation before calculating the digital signature but must transfer the data without the universal line delimiter transformation. Similarly, recipients must apply the universal line delimiter transformation before calculating the digital signature. NOTE: An originator can not transfer the content with the universal line delimiter transformation intact because the transformation process is not idempotent. In particular, SMTP servers may themselves convert the universal line delimiter to a local line delimiter, prior to the message being delivered to the user. Thus, a recipient has no way of knowing if the transformation is present or not. Thus, if the recipient applies the transformation to a content in which it is already present, the resulting content may have two line delimiters Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 4]
INTERNET DRAFT PEM and MIME June 1994 present, which would cause the verification of the signature to fail. 3.1.3. Step 3: Security Form Either of the digital signature or encryption services is applied to a content. The content to be protected is prepared by a MIME implementation and made available to a PEM implementation according to a local convention. The PEM implementation must produce two outputs: the data that has been protected and the control information necessary to verify or remove the protection. These outputs must be made available to the MIME implementation which will construct a multipart/signed or multipart/encrypted content, according to the service requested. The multipart content replaces the content that was selected for protection. 3.2. Use of multipart/signed Content Type When this content type is used, the value of the required parameter "protocol" is "pem" and the value of the required parameter "hashalg" is one of the valid choices from [5], for example: Content-Type: multipart/signed; protocol="pem"; hashalg="md5"; boundary="Signed Message" --Signed Message Content-Type: text/plain This is some example text. --Signed Message Content-Type: application/signature <pemsig> --Signed Message-- where the <pemsig> token is defined as follows. Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 5]
INTERNET DRAFT PEM and MIME June 1994 <pemsig> ::= <version> (1*<origasymflds>) <version> ::= "Version:" "5" CRLF <origasymflds> ::= <origid> <micinfo> <origid> ::= "Originator-ID:" <id> CRLF The token <id> is defined in Section ??. The only valid value for a Content-Transfer-Encoding: header, if included, is "7bit". 3.3. Use of multipart/encrypted Content Type When this content type is used, the value of the required parameter "protocol" is "pem", for example: Content-Type: multipart/encrypted; protocol="pem"; boundary="Encrypted Message" --Encrypted Message Content-Type: application/keys <pemkeys> --Encrypted Message Content-Type: application/octet-stream <encrypted data> --Encrypted Message-- where the <pemkeys> token is defined as follows. <pemkeys> ::= <version> <dekinfo> 1*<recipasymflds> <version> ::= "Version:" "5" CRLF <recipasymflds> ::= <recipid> <asymkeyinfo> <recipid> ::= "Recipient-ID:" <id> CRLF <asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 6]
INTERNET DRAFT PEM and MIME June 1994 The token <id> is defined in Section ??. 4. Removing PEM Security Services from PEM Body Parts Upon receipt of a multipart/signed or multipart/encrypted body part, the PEM security services are removed by reversing the sequence of steps specified in Section ??, modifying step 2 as follows. (1) All content types must have their line delimiters canonicalized prior to removing the PEM security services. (2) Outer layers of PEM security services must be processed prior to processing inner layers of PEM security services. Processing includes a user choosing to display a content without removing the PEM security services. 5. Definition of New Name Forms WARNING: This is the first draft of this section. Although conceptually it represents a direction that will not change, while this document is an internet draft the details of the specification are subject to change at any time, without notice, owing to comments and implementation experience. Implementors are encouraged to contact the authors for the current status. Currently, [3] requires the use of certificates to specify the public key used to create a PEM message. Within certificates, [4] requires the use of distinguished names as specified by the X.500 Series of Recommendations. However, the Internet community has a great deal more experience with the use of electronic mail addresses as identifiers and there is a desire to be able to use arbitrary strings to identify the owners of public keys. Hence, there is a need to support name forms which do not conform to the expected usage of distinguished names. In addition, users may distribute their public keys via mechanisms outside the scope of the PEM specification, for example, in a file via FTP as opposed to in a certificate. As a result, it is desirable to be able to explicitly specify the public key used rather than an identifier of the public key. The objective of the various Originator and Recipient fields specified in [3] is to indicate which public key has been used or is required. This document simplifies the set of fields by specifying exactly two: Originator-ID: for originators and Recipient-ID: for recipients. The Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 7]
INTERNET DRAFT PEM and MIME June 1994 value of each of these fields is indicated by the token <id>, which is defined as follows. <id> ::= <id-email> / <id-string> / <id-dname> / <id-publickey> / <id-issuer> <id-email> ::= "EN" "," <atstring> "," <hashalgid> "," <hashpublickey> <id-string> ::= "STR" "," <string> "," <hashalgid> "," <hashpublickey> <id-dname> ::= "DN" "," <dname> "," <hashalgid> "," <hashpublickey> <id-publickey> ::= "PK" "," "," <pkalgid> "," <publickey> "," ( <string> / <atstring> ) <id-issuer> ::= "IS" "," <dname> "," <serial> <atstring> ::= <encbin> ; a printably encoded, ASN.1 encoded ; string containing exactly one '@' <string> ::= <encbin> ; "a sequence of characters excluding '@'" ; a printably encoded, ASN.1 value <hashalgid> ::= "to be defined by RFC 1423" <hashpublickey> ::= 1*<hexchar> ; hex dump of the <hashalgid> hash of the ; public key <pkalgid> ::= "to be defined by RFC 1423" <publickey> ::= <encbin> ; a printably encoded, ASN.1 encoded public key <dname> ::= <encbin> ; a printably encoded, ASN.1 encoded ; distinguished name <serial> ::= 1*<hexchar> ; hex dump of the serial number of a certificate The inclusion of the hash of the public key is intended to facilitate the recognition of which public key among several that may be associated with the string or distinguished name. Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 8]
INTERNET DRAFT PEM and MIME June 1994 The identifiers <id-email> and <id-string> are distinguished only by the presence or absence of the character '@'. In all other respects they are equivalent and are encoded strings that are to be used as the subject name in a certificate. This distinguishing characteristic was chosen as opposed to defining a new object identifier to represent email addresses because of the perceived difficulty in distributing and implementing the definition of a new object identifier. The <id-publickey> identifier allows for the direct distribution and indication of the public key that was or is to be used to process the message. The <id-issuer> identifier is included for backward compatibility with the ID-ASymmetric fields defined in [3]. The older fields are easily converted to this new form by prefixing the old value with "IS," and replacing the field name with an appropriate new ID field. 6. Definition of New Content Types This document defines two new content types, the contents of which comprise a replacement mechanism for [6]. The first content type is application/key-request, which replaces the certification and CRL- retrieval request messages. The second content type is application/key-data, which replaces the certification reply message, the crl-storage request message, and the crl-retrieval reply message. There were no requirements for a crl-storage reply message and none are specified in this document. This document includes a specification for a certificate request message, which was previously undefined. NOTE: RFC1424 has some descriptive text, especially for certification messages, that should probably be included. 6.1. application/key-request Content Type Definition (1) MIME type name: application (2) MIME subtype name: key-request (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: quoted-printable is always sufficient Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 9]
INTERNET DRAFT PEM and MIME June 1994 (6) Security Considerations: none The content of this body part corresponds to the following production. <request> ::= <version> ( <subject> / <issuer> / <certification> ) <version> ::= "Version:" "5" CRLF <subject> ::= "Subject:" <id> CRLF <issuer> ::= "Issuer:" <id> CRLF <certification> ::= "Certification:" <encbin> CRLF This content type is used to provide for some of the requests described in [6]. The information in the body part is entirely independent of any other body part. As such, the application/key-request content type is an independent body part. The certification request, certificate-retrieval request and crl- retrieval request are provided for directly. If the content contains a Certification: field it requests certification of the self-signed certificate in the field value. If the content contains an Issuer: field it requests the certificate revocation list chain beginning with the issuer identified in the field value. If the content contains a Subject: field it requests the certificate chain beginning with the subject identified in the field value. The Subject: and Issuer: fields each contain a value of type Name, encoded according to the Basic Encoding Rules, then in ASCII, as for the Originator-ID-Asymmetric: field of [3]. The crl-storage request is provided for by the application/key-data content type described in the next section. In each case, the response is transmitted in an application/key-data content type. When returning certificate and certificate revocation list chains, if there exists more than one chain, several application/key-data contents are to be returned in the reply message, one for each chain. 6.2. application/key-data Content Type Definition (1) MIME type name: application Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 10]
INTERNET DRAFT PEM and MIME June 1994 (2) MIME subtype name: key-data (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: quoted-printable is always sufficient. (6) Security Considerations: none The content of this body part corresponds to the following production. <certdata> ::= <certchain> / <crlchain> <certchain> ::= <version> <cert> *( [ <crl> ] <cert> ) <crlchain> ::= <version> 1*( <crl> [ <cert> ] ) <cert> ::= "Certificate:" <encbin> CRLF <crl> ::= "CRL:" <encbin> CRLF <version> ::= "Version:" "5" CRLF This content type is used to transfer certificate or Certificate Revocation List (CRL) information. The information in the body part is entirely independent of any particular privacy enhanced message. (Note that the converse is not true: the validity of a privacy enhanced message cannot be determined without the proper certificates or current CRL information.) As such, the application/key-data content type is an independent body part. The <certchain> production contains one certificate chain. A certificate chain starts with a certificate and continues with the certificates of subsequent issuers. Each issuer certificate included must have issued the preceding certificate. For each issuer, a CRL may be supplied. A CRL in the chain belongs to the immediately following issuer. Therefore, it potentially contains the immediately preceding certificate. The <crlchain> production contains one certificate revocation list chain. The CRLs in the chain begin with the requested CRL and continue with the CRLs of subsequent issuers. The issuer of each CRL is presumed to have issued a certificate for the issuer of the preceding CRL. For each CRL, the issuer's certificate may be supplied. A certificate in the chain must belong to the issuer of the immediately preceding CRL. Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 11]
INTERNET DRAFT PEM and MIME June 1994 The relationship between a certificate and an immediately preceding CRL is the same in both cases. In a <certchain> the crl's are optional. In a <crlchain> the certificates are optional. 7. Message Processing When a user composes a message, it is the responsibility of the user agent to construct a valid MIME message. In particular, Content-Type: and Content-Transfer-Encoding: headers should be used wherever they are appropriate. This allows the receiving user agent to unambiguously interpret the message body and process it accordingly. Each block of content headers associated with either an RFC822 <message> or with a MIME <body-part> represents a logical place where security enhancement can be requested. A security enhancement request associated with a particular <message> or <body-part> content is taken to apply to the entire content; it is not possible to security-enhance only a portion of a body part. The mechanism used to communicate security enhancement requests to the pre-submission processor described below is strictly a local implementation issue. However, the interface between the message composer and pre-submission processing MUST be trustworthy, since the message composer relies on pre-submission processing to either perform the requested security enhancement operation or return an error. Regardless of the mechanism chosen, great care should be taken to safeguard against both the release of information that has not received the requested type of security enhancement as well as tampering with the enhancement request itself. 7.1. Pre-Submission Algorithm The user agent first composes a MIME-compliant message and then applies this algorithm: (1) If the content at this (initially top) level has NOT been selected for security enhancement, the user agent sees if the content is either multipart or message. If so, it then recursively applies this algorithm to the encapsulated body parts; if not, it terminates processing for this content. (2) If the content at this level has been selected for security enhancement, then the content, including its headers, constitutes the object that is to be made available to the security enhancement process. The headers at a minimum will include a Content-Type Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 12]
INTERNET DRAFT PEM and MIME June 1994 header, either explicit or implicit. The object will eventually be replaced with the multipart content that is produced by the security enhancement operation. (3) The selected security enhancement is performed. This enhancement produces two data streams: the enhanced object and a control stream comprised of a set of headers as defined in the <pemsig> or <pemkeys> productions. (4) A new body part is then constructed, of content type multipart/signed or multipart/encrypted. The new body part contains two body parts, whose content depends on the enhancement requested, which are constructed according to the specifications in this document. (5) This multipart content replaces the original object. 7.2. Post-Delivery Algorithm When a user receives a message containing a multipart content, the user agent may transform the content back into its original form prior to privacy-enhancement. This operation, the post-delivery algorithm, is performed by reversing the steps performed during the pre-submission algorithm. When the original content is reconstituted, it may use octet values outside of the US-ASCII repertoire and may contain body parts without line breaks. If the user agent replaces the multipart content with the original content, then it must select appropriate Content-Transfer- Encodings for each body part and add corresponding Content-Transfer- Encoding: headers. Upon successful completion of the post-delivery algorithm for each content, the type of enhancement that was in effect for that content must be communicated to the user. The mechanism used to do this is a local implementation issue. As with requests for enhancement to the pre-submission algorithm, the path between post-delivery processing and actual display of the message must be a trusted one, lest a message be presented that purports to have undergone some form of enhancement it did not in fact receive. 8. Examples NOTE: To be included upon completion of implementation. Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 13]
INTERNET DRAFT PEM and MIME June 1994 9. Observations The use of the pre-submission and post-delivery algorithms to combine PEM and MIME capabilities exhibits several properties: (1) It allows privacy-enhancement of an arbitrary content, not just the body of an RFC 822 message. (2) For a multipart or message content, it allows the user to specify different privacy enhancements to be applied to different components of the structure of the content. (3) It provides for messages containing several privacy enhanced contents, thereby removing the requirement for PEM software to be able to generate or interpret a single content which intermixes both unenhanced and enhanced components. The use of a MIME-capable user agent makes complex nesting of enhanced message body parts much easier. For example, the user can separately sign and encrypt a message. This motivates a complete separation of the confidentiality security service from the digital signature security service. That is, different keys could be used for the different services and could be protected separately. In the asymmetric case, this means an employee's company could be given access to the (private) decryption key but not the (private) signature key, thereby granting the company the ability to decrypt messages addressed to the employee in emergencies without also granting the company the ability to sign messages as the employee. The use of two private keys requires the ability to maintain multiple certificates for each user. 10. Summary of Changes to PEM Specification This document updates the message encryption and signature procedures defined by [3] and obsoletes the key certification and related services defined by [6]. The changes are enumerated below. (1) The PEM specification currently requires that encryption services be applied only to message bodies that have been signed. By providing for each of the services separately, they may be applied recursively in any order according to the needs of the requesting application. Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 14]
INTERNET DRAFT PEM and MIME June 1994 (2) PEM implementations are currently restricted to processing only text-based electronic mail messages. In fact, the message text is required to be represented by the ASCII character set with "<CR><LF>" line delimiters. This restriction no longer applies. (3) With the removal of the text restriction it is not possible to specify a universal canonical form. However, canonicalization is required for the digital signature service, so the content of each body part must be transformed into a canonical form according to its type. (4) MIME includes transfer encoding operations to ensure the unmodified transfer of body parts, which obviates these services in PEM. (5) PEM specifies a Proc-Type: header field to identify the type of processing that was performed on the message. This functionality is subsumed by the MIME Content-Type: headers. The Proc-Type: header also included a decimal number that was used to distinguish among incompatible encapsulated header field interpretations which may arise as changes are made to the PEM standard. This functionality is replaced by the Version: header specified in this document. (6) PEM specifies a Content-Domain: header, the purpose of which is to describe the type of the content which is represented within a PEM message's encapsulated text. This functionality is subsumed by the MIME Content-Type: headers. (7) The PEM specifications include a document that defines new types of PEM messages, specified by unique values used in the Proc-Type: header, to be used to request certificate and certificate revocation list information. This functionality is subsumed by two new content types specified in this document. (8) The header fields having to do with certificates (Originator- Certificate: and Issuer-Certificate:) and CRLs (CRL:) are relegated for use only in the application/key-data and application/key- request content types and are no longer allowed in the header portion of a PEM signed or encrypted message. (9) The grammar specified here explicitly separates the header fields that may appear for the encryption and signature security services. It is the intent of this document to specify a precise expression of the allowed header fields; there is no intent to reduce the functionality of combinations of encryption and signature security Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 15]
INTERNET DRAFT PEM and MIME June 1994 from those of [3]. (10) With the separation of the encryption and signature security services, there is no need for a MIC-Info: field in the headers associated with an encrypted message under asymmetric key management. (11) In [3], when asymmetric key management is used, an Originator-ID field is required in order to identify the private key used to sign the MIC argument in the MIC-Info: field. Because no MIC-Info: field is associated with the encryption security service under asymmetric key managment, there is no requirement in that case to include an Originator-ID field. These changes represent a departure in mechanism, not in effect, from those specified in [3] and [6]. The following technical changes to [3] and [4] are also specified by this document. (1) The grammar specified here explicitly excludes symmetric key management. Currently, there are no generally available implementations of symmetric key management nor are there any known plans for implementing it. As a result, the IETF standards process will require this feature to be dropped when the documents are promoted to draft standard status from proposed standard status. (2) This document requires all data that is to be digitally signed to be represented in 7bit form. (3) This document relaxes the syntax of distinguished names. In particular, distinguished names are not constrained to conform to the X.500 Series of Recommendations. Instead users may use arbitrary strings and email addresses as their name. Further, users may distribute their public key directly in lieu of using certificates. In support of this change the Originator-ID- ASymmetric: and Recipient-ID-ASymmetric: fields are deprecated in favor of Originator-ID: and Recipient-ID: fields, respectively. 11. Collected Grammar The following is a summary of the grammar presented in this document. (1) Signature headers Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 16]
INTERNET DRAFT PEM and MIME June 1994 <pemsig> ::= <version> (1*<origasymflds>) <version> ::= "Version:" "5" CRLF <origasymflds> ::= <origid> <micinfo> <origid> ::= "Originator-ID:" <id> CRLF (2) Encryption Headers <pemkeys> ::= <version> <dekinfo> 1*<recipasymflds> <version> ::= "Version:" "5" CRLF <recipasymflds> ::= <recipid> <asymkeyinfo> <recipid> ::= "Recipient-ID:" <id> CRLF <asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF (3) Request Headers (certificate, certification, etc.) <request> ::= <version> ( <subject> / <issuer> / <certification> ) <version> ::= "Version:" "5" CRLF <subject> ::= "Subject:" <id> CRLF <issuer> ::= "Issuer:" <id> CRLF <certification> ::= "Certification:" <encbin> CRLF (4) Certificate Headers (certificate, certification revocation list) <certdata> ::= <certchain> / <crlchain> <certchain> ::= <version> <cert> *( [ <crl> ] <cert> ) <crlchain> ::= <version> 1*( <crl> [ <cert> ] ) <cert> ::= "Certificate:" <encbin> CRLF <crl> ::= "CRL:" <encbin> CRLF <version> ::= "Version:" "5" CRLF Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 17]
INTERNET DRAFT PEM and MIME June 1994 12. Security Considerations NOTE: to be done 13. Acknowledgements David H. Crocker suggested the use of a multipart structure for MIME-PEM interaction. 14. References [1] David H. Crocker. Standard for the Format of ARPA Internet Text Messages. RFC 822, University of Delaware, August 1982. [2] Nathaniel Borenstein and Ned Freed. MIME (Multipurpose Internet Mail Extension) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. RFC 1521, Bellcore and Innosoft, September 1993. Obsoletes RFC 1341. [3] John Linn. Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures. RFC 1421, February 1993. Obsoletes RFC 1113. [4] Steve Kent. Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management. RFC 1422, BBN Communications, February 1993. [5] David M. Balenson. Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers. RFC 1423, Trusted Information Systems, February 1993. [6] Burton S. Kaliski. Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services. RFC 1424, RSA Laboratories, February 1993. [7] David Crocker. Multipart/Family Content Types. Work in progress. [8] James Galvin. Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. Work in progress. [9] Jon Postel. Simple Mail Transfer Protocol. RFC 821, ISI, August 1982. Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 18]
INTERNET DRAFT PEM and MIME June 1994 15. Authors' Addresses Steve Crocker Trusted Information Systems 3060 Washington Road Glenwood, MD 21738 Tel: +1 301 854 6889 FAX: +1 301 854 5363 email: crocker@tis.com Ned Freed Innosoft International, Inc. 250 West First Street, Suite 240 Claremont, CA 91711 Tel: +1 909 624 7907 FAX: +1 909 621 5319 email: ned@innosoft.com James M. Galvin Trusted Information Systems 3060 Washington Road Glenwood, MD 21738 Tel: +1 301 854 6889 FAX: +1 301 854 5363 email: galvin@tis.com Sandra Murphy Trusted Information Systems 3060 Washington Road Glenwood, MD 21738 Tel: +1 301 854 6889 FAX: +1 301 854 5363 email: murphy@tis.com Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 19]
INTERNET DRAFT PEM and MIME June 1994 16. Appendix: Imported Grammar The following productions are taken from [3]. The grammar presented in [3] remains the authoritative source for these productions; they are repeated here for the convenience of the reader. <dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF <micinfo> ::= "MIC-Info" ":" <micalgid> "," <ikalgid> "," <asymsignmic> CRLF <encbin> ::= 1*<encbingrp> <encbingrp> ::= 4*4<encbinchar> <encbinchar> ::= ALPHA / DIGIT / "+" / "/" / "=" The following productions are taken from [5]. The grammar presented in [5] remains the authoritative source for these productions; they are repeated here for the convenience of the reader. <dekalgid> ::= "DES-CBC" <ikalgid> ::= "DES-EDE" / "DES-ECB" / "RSA" <micalgid> ::= "RSA-MD2" / "RSA-MD5" <dekparameters> ::= <DESCBCparameters> <DESCBCparameters> ::= <IV> <IV> ::= <hexchar16> <asymsignmic> ::= <RSAsignmic> <RSAsignmic> ::= <encbin> <asymencdek> ::= <RSAencdek> <RSAencdek> ::= <encbin> <hexchar16> ::= 16*16<hexchar> <hexchar> ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F" ; no lower case Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 20]
INTERNET DRAFT PEM and MIME June 1994 Table of Contents 1 Status of this Memo ............................................. 1 2 Abstract ........................................................ 1 3 Applying PEM Security Services to MIME Body Parts ............... 2 3.1 PEM Processing Steps .......................................... 3 3.1.1 Step 1: Local Form .......................................... 3 3.1.2 Step 2: Canonical Form ...................................... 3 3.1.3 Step 3: Security Form ....................................... 5 3.2 Use of multipart/signed Content Type .......................... 5 3.3 Use of multipart/encrypted Content Type ....................... 6 4 Removing PEM Security Services from PEM Body Parts .............. 7 5 Definition of New Name Forms .................................... 7 6 Definition of New Content Types ................................. 9 6.1 application/key-request Content Type Definition ............... 9 6.2 application/key-data Content Type Definition .................. 10 7 Message Processing .............................................. 12 7.1 Pre-Submission Algorithm ...................................... 12 7.2 Post-Delivery Algorithm ....................................... 13 8 Examples ........................................................ 13 9 Observations .................................................... 14 10 Summary of Changes to PEM Specification ........................ 14 11 Collected Grammar .............................................. 16 12 Security Considerations ........................................ 18 13 Acknowledgements ............................................... 18 14 References ..................................................... 18 15 Authors' Addresses ............................................. 19 16 Appendix: Imported Grammar ..................................... 20 Crocker/Freed/Galvin/Murphy Expires: December 1994 [Page 21]
