RFCs in HTML Format


RFC 1848

                     MIME Object Security Services

Table of Contents

   1.  Introduction .............................................    3
   2.  Applying MIME Object Security Services ...................    4
   2.1  Digital Signature Service ...............................    4
   2.1.1  Canonicalization ......................................    5
   2.1.2  Digital Signature Control Information .................    7
   2.1.2.1  Version: ............................................    8
   2.1.2.2  Originator-ID: ......................................    8
   2.1.2.3  MIC-Info: ...........................................    8
   2.1.3  application/moss-signature Content Type Definition ....    9
   2.1.4  Use of multipart/signed Content Type ..................   10
   2.2  Encryption Service ......................................   11



Crocker, et al              Standards Track                     [Page 1]

RFC 1848 MIME Object Security Services October 1995 2.2.1 Encryption Control Information ........................ 12 2.2.1.1 DEK-Info: ........................................... 13 2.2.1.2 Recipient-ID: ....................................... 14 2.2.1.3 Key-Info: ........................................... 14 2.2.2 application/moss-keys Content Type Definition ......... 15 2.2.3 Use of multipart/encrypted Content Type ............... 16 3. Removing MIME Object Security Services ................... 17 3.1 Digital Signature Service ............................... 18 3.1.1 Preparation ........................................... 18 3.1.2 Verification .......................................... 19 3.1.3 Results ............................................... 19 3.2 Encryption Service ...................................... 20 3.2.1 Preparation ........................................... 20 3.2.2 Decryption ............................................ 20 3.2.3 Results ............................................... 21 4. Identifying Originators, Recipients, and Their Keys ...... 21 4.1 Name Forms .............................................. 23 4.1.1 Email Addresses ....................................... 23 4.1.2 Arbitrary Strings ..................................... 23 4.1.3 Distinguished Names ................................... 23 4.2 Identifiers ............................................. 24 4.2.1 Email Address ......................................... 25 4.2.2 Arbitrary String ...................................... 25 4.2.3 Distinguished Name .................................... 26 4.2.4 Public Key ............................................ 26 4.2.5 Issuer Name and Serial Number ......................... 27 5. Key Management Content Types ............................. 27 5.1 application/mosskey-request Content Type Definition ..... 28 5.2 application/mosskey-data Content Type Definition ........ 29 6. Examples ................................................. 31 6.1 Original Message Prepared for Protection ................ 31 6.2 Sign Text of Original Message ........................... 32 6.3 Sign Headers and Text of Original Message ............... 32 6.4 Encrypt Text of a Message ............................... 33 6.5 Encrypt the Signed Text of a Message .................... 35 6.6 Protecting Audio Content ................................ 37 6.6.1 Sign Audio Content .................................... 37 6.6.2 Encrypt Audio Content ................................. 37 7. Observations ............................................. 38 8. Comparison of MOSS and PEM Protocols ..................... 39 9. Security Considerations .................................. 41 10. Acknowledgements ........................................ 41 11. References .............................................. 41 12. Authors' Addresses ...................................... 43 Appendix A: Collected Grammar .............................. 44 Appendix B: Imported Grammar ............................... 47 Crocker, et al Standards Track [Page 2]
RFC 1848 MIME Object Security Services October 1995 1. Introduction MIME [2], 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. 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 STD 11, RFC 822 [1], whilst the body, if structured, is defined according to MIME. MIME does not provide for the application of security services. PEM [3-6], an acronym for "Privacy Enhanced Mail", defines message encryption and message authentication procedures for text-based electronic mail messages using a certificate-based key management mechanism. The specifications include several features that are easily and more naturally supported by MIME, for example, the transfer encoding operation, the Content-Domain header, and the support services specified by its Part IV [6]. The specification is limited by specifying the application of security services to text messages only. MOSS is based in large part on the PEM protocol as defined by RFC 1421. Many of PEMs features and most of its protocol specification are included here. A comparison of MOSS and PEM may be found in Section 8. In order to make use of the MOSS services, a user (where user is not limited to being a human, e.g., it could be a process or a role) is required to have at least one public/private key pair. The public key must be made available to other users with whom secure communication is desired. The private key must not be disclosed to any other user. An originator's private key is used to digitally sign MIME objects; a recipient would use the originator's public key to verify the digital signature. A recipient's public key is used to encrypt the data encrypting key that is used to encrypt the MIME object; a recipient would use the corresponding private key to decrypt the data encrypting key so that the MIME object can be decrypted. As long as the private keys are protected from disclosure, i.e., the private keys are accessible only to the user to whom they have been assigned, the recipient of a digitally signed message will know from whom the message was sent and the originator of an encrypted message will know that only the intended recipient is able to read it. For assurance, the ownership of the public keys used in verifying digital signatures and encrypting messages should be verified. A stored public key should be protected from modification. Crocker, et al Standards Track [Page 3]
RFC 1848 MIME Object Security Services October 1995 The framework defined in [7] provides an embodiment of a MIME object and its digital signature or encryption keys. When used by MOSS the framework provides digital signature and encryption services to single and multi-part textual and non-textual MIME objects. 2. Applying MIME Object Security Services The application of the MOSS digital signature service requires the following components. (1) The data to be signed. (2) The private key of the originator. The data to be signed is prepared according to the description below. The digital signature is created by generating a hash of the data and encrypting the hash value with the private key of the originator. The digital signature, some additional ancillary information described below, and the data are then embodied in a multipart/signed body part. Finally, the multipart/signed body part may be transferred to a recipient or processed further, for example, it may be encrypted. The application of the MOSS encryption service requires the following components. (1) The data to be encrypted. (2) A data encrypting key to encrypt the data. (3) The public key of the recipient. The data to be encrypted is prepared according to the description below. The originator creates a data encrypting key and encrypts the data. The recipient's public key is used to encrypt the data encrypting key. The encrypted data, the encrypted data encrypting key, and some additional ancillary information described below are then embodied in a multipart/encrypted body part, ready to be transferred to a recipient or processed further, for example, it may be signed. The next two sections describe the digital signature and encryption services, respectively, in detail. 2.1. Digital Signature Service The MOSS digital signature service is applied to MIME objects, specifically a MIME body part. The MIME body part is created Crocker, et al Standards Track [Page 4]
RFC 1848 MIME Object Security Services October 1995 according to a local convention and then made available to the digital signature service. The following sequence of steps comprises the application of the digital signature service. (1) The body part to be signed must be canonicalized. (2) The digital signature and other control information must be gen- erated. (3) The control information must be embodied in an appropriate MIME content type. (4) The control information body part and the data body part must be embodied in a multipart/signed content type. Each of these steps is described below. 2.1.1. Canonicalization The body part must be converted to a canonical form that is uniquely and unambiguously representable in at least the environment where the digital signature is created and the environment where the digital signature will be verified, i.e., the originator and recipient's environment, respectively. 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 create the digital signature value while the recipient needs to be able to compare a re-computed value with the received value. If the canonical form is representable on many different host computers, the 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. The canonicalization transformation is a two step process. First, the body part must be converted to a form that is unambiguously representable on as many different host computers as possible. Second, the body part must have its line delimiters converted to a unique and unambiguous representation. The representation chosen to satisfy the first step is 7bit, as defined by MIME; the high order bit of each octet of the data to be Crocker, et al Standards Track [Page 5]
RFC 1848 MIME Object Security Services October 1995 signed must be zero. A MIME body part is comprised of two parts: headers and content. Since the headers of body parts are already required to be represented in 7bit, this step does not require changes to the headers. This step requires that if the content is not already 7bit then it must be encoded with an appropriate MIME content transfer encoding and a Content-Transfer-Encoding: header must be added to the headers. For example, if the content to be signed contains 8bit or binary data, the content must be encoded with either the quoted-printable or base64 encoding as defined by MIME. IMPLEMENTORS NOTE: Since the MIME standard explicitly disallows nested content transfer encodings, i.e., the content types multipart and message may not themselves be encoded, the 7bit transformation requires each nested body part to be individually encoded in a 7bit representation. Any valid MIME encoding, e.g., quoted-printable or base64, may be used and, in fact, a different encoding may be used on each of the non-7bit body parts. Representing all content types in a 7bit format transforms them into text-based content types. However, text-based content types present a unique problem. In particular, the line delimiter used for a text-based content type is specific to a local environment; different environments use the single character carriage-return (<CR>), the single character line-feed (<LF>), or the two character sequence "carriage-return line-feed (<CR><LF>)". 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 second step of the canonicalization transformation includes the conversion of the local line delimiter to the two character sequence "<CR><LF>". The conversion to the canonical line delimiter is only required for the purposes of computing the digital signature. Thus, originators must apply the line delimiter conversion before computing the digital signature but must transfer the data without the line delimiter conversion. Similarly, recipients must apply the line delimiter conversion before computing the digital signature. NOTE: An originator can not transfer the content with the line delimiter conversion intact because the conversion process is not idempotent. In particular, SMTP servers may themselves convert the line delimiter to a local line delimiter, prior to the message being delivered to the recipient. Thus, a recipient has no way of knowing if the conversion is present or not. If the recipient applies the conversion to a content in which it is already present, the resulting content may have two line delimiters Crocker, et al Standards Track [Page 6]
RFC 1848 MIME Object Security Services October 1995 present, which would cause the verification of the signature to fail. IMPLEMENTORS NOTE: Implementors should be aware that the conversion to a 7bit representation is a function that is required in a minimally compliant MIME user agent. Further, the line delimiter conversion required here is distinct from the same conversion included in that function. Specifically, the line delimiter conversion applied when a body part is converted to a 7bit representation (transfer encoded) is performed prior to the application of the transfer encoding. The line delimiter conversion applied when a body part is signed is performed after the body part is converted to 7bit (transfer encoded). Both line delimiter conversions are required. 2.1.2. Digital Signature Control Information The application of the digital signature service generates control information which includes the digital signature itself. The syntax of the control information is that of a set of RFC 822 headers, except that the folding of header values onto continuation lines is explicitly forbidden. Each header and value pair generated by the digital signature service must be output on exactly one line. The complete set of headers generated by the digital signature service is as follows. Version: indicates which version of the MOSS protocol the remaining headers represent. Originator-ID: indicates the private key used to create the digital signature and the corresponding public key to be used to verify it. MIC-Info: contains the digital signature value. Each invocation of the digital signature service must emit exactly one Version: header and at least one pair of Originator-ID: and MIC- Info: headers. The Version: header must always be emitted first. The Originator-ID: and MIC-Info: headers are always emitted in pairs in the order indicated. This specification allows an originator to generate multiple signatures of the data, presumably with different signature algorithms, and to include them all in the control information. The interpretation of the presence of multiple signatures is outside the scope of this specification except that a MIC-Info: header is always interpreted in the context of the Crocker, et al Standards Track [Page 7]
RFC 1848 MIME Object Security Services October 1995 immediately preceding Originator-ID: header. 2.1.2.1. Version: The version header is defined by the grammar token <version> as follows. <version> ::= "Version:" "5" CRLF Its value is constant and MOSS implementations compliant with this specification must recognize only this value and generate an error if any other value is found. 2.1.2.2. Originator-ID: The purpose of the originator header is two-fold: to directly identify the public key to be used to verify the digital signature and to indirectly identify the user who owns both it and its corresponding private key. Typically, a recipient is less interested in the actual public key value, although obviously the recipient needs the value to verify the signature, and more interested in identifying its owner. Thus, the originator header may convey either or both pieces of information: the public key to be used to verify the signature the name of the owner and which of the owner's public keys to use to verify the signature The decision as to what information to place in the value rests entirely with the originator. The suggested value is to include both. Recipients with whom the originator has previously communicated will have to verify that the information presented is consistent with what is already known. New recipients will want all of the information, which they will need to verify prior to storing in their local database. The originator header is defined by the grammar token <origid> as follows. <origid> ::= "Originator-ID:" <id> CRLF The grammar token <id> is defined in Section 4. 2.1.2.3. MIC-Info: The purpose of the Message Integrity Check (MIC) header is to convey the digital signature value. Its value is a comma separated list of Crocker, et al Standards Track [Page 8]
RFC 1848 MIME Object Security Services October 1995 three arguments: the hash (or MIC) algorithm identifier, the signature algorithm identifier, and the digital signature. The MIC header is defined by the grammar token <micinfo> as follows. <micinfo> ::= "MIC-Info:" <micalgid> "," <ikalgid> "," <asymsignmic> CRLF The grammar tokens for the MIC algorithms and identifiers (<micalgid>), signature algorithms and identifiers (<ikalgid>), and signed MIC formats (<asymsignmic>) are defined by RFC 1423. They are also reprinted in Appendix B. IMPLEMENTORS NOTE: RFC 1423 is referenced by the PEM protocol, which includes support for symmetric signatures and key management. As a result, some of the grammar tokens defined there, for example, <ikalgid>, will include options that are not legal for this protocol. These options must be ignored and have not been included in the appendix. 2.1.3. application/moss-signature Content Type Definition (1) MIME type name: application (2) MIME subtype name: moss-signature (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: quoted-printable is always sufficient (6) Security considerations: none The "application/moss-signature" content type is used on the second body part of an enclosing multipart/signed. Its content is comprised of the digital signature of the data in the first body part of the enclosing multipart/signed and other control information required to verify that signature, as defined by Section 2.1.2. The label "application/moss-signature" must be used as the value of the protocol parameter of the enclosing multipart/signed; the protocol parameter must be present. Part of the signature verification information will be the Message Integrity Check (MIC) algorithm(s) used during the signature creation process. The MIC algorithm(s) identified in this body part must match the MIC algorithm(s) identified in the micalg parameter of the enclosing multipart/signed. If it does (they do) not, a user agent Crocker, et al Standards Track [Page 9]
RFC 1848 MIME Object Security Services October 1995 should identify the discrepancy to a user and it may choose to either halt or continue processing, giving precedence to the algorithm(s) identified in this body part. An application/moss-signature body part is constructed as follows: Content-Type: application/moss-signature <mosssig> where the grammar token <mosssig> is defined as follows. <mosssig> ::= <version> ( 1*<origasymflds> ) <version> ::= "Version:" "5" CRLF <origasymflds> ::= <origid> <micinfo> <origid> ::= "Originator-ID:" <id> CRLF <micinfo> ::= "MIC-Info:" <micalgid> "," <ikalgid> "," <asymsignmic> CRLF The token <id> is defined in Section 4. All other tokens are defined in Section 2.1.2.3. 2.1.4. Use of multipart/signed Content Type The definition of the multipart/signed content type in [7] specifies three steps for creating the body part. (1) The body part to be digitally signed is created according to a local convention, for example, with a text editor or a mail user agent. (2) The body part is prepared for the digital signature service according to the protocol parameter, in this case according to Section 2.1.1. (3) The prepared body part is digitally signed according to the protocol parameter, in this case according to Section 2.1.2. The multipart/signed content type is constructed as follows. Crocker, et al Standards Track [Page 10]
RFC 1848 MIME Object Security Services October 1995 (1) The value of its required parameter "protocol" is set to "application/moss-signature". (2) The signed body part becomes its first body part. (3) Its second body part is labeled "application/moss-signature" and is filled with the control information generated by the digital signature service. (4) The value of its required parameter "micalg" is set to the same value used in the MIC-Info: header in the control information. If there is more than one MIC-Info: header present the value is set to a comma separated list of values from the MIC-Info headers. The interpretation of the order of the list of values is outside the scope of this specification. A multipart/signed content type with the MOSS protocol might look as follows: Content-Type: multipart/signed; protocol="application/moss-signature"; micalg="rsa-md5"; boundary="Signed Message" --Signed Message Content-Type: text/plain This is some example text. --Signed Message Content-Type: application/moss-signature Version: 5 Originator-ID: ID-INFORMATION MIC-Info: RSA-MD5,RSA,SIGNATURE-INFORMATION --Signed Message-- where ID-INFORMATION and SIGNATURE-INFORMATION are descriptive of the content that would appear in a real body part. 2.2. Encryption Service The MOSS encryption service is applied to MIME objects, specifically a MIME body part. The MIME body part is created according to a local convention and then made available to the encryption service. Crocker, et al Standards Track [Page 11]
RFC 1848 MIME Object Security Services October 1995 The following sequence of steps comprises the application of the encryption service. (1) The body part to be encrypted must be in MIME canonical form. (2) The data encrypting key and other control information must be generated. (3) The control information must be embodied in an appropriate MIME content type. (4) The control information body part and the encrypted data body part must be embodied in a multipart/encrypted content type. The first step is defined by MIME. The latter three steps are described below. 2.2.1. Encryption Control Information The application of the encryption service generates control information which includes the data encrypting key used to encrypt the data itself. The syntax of the control information is that of a set of RFC 822 headers, except that the folding of header values onto continuation lines is explicitly forbidden. Each header and value pair generated by the encryption service must be output on exactly one line. First, the originator must retrieve the public key of the recipient. The retrieval may be from a local database or from a remote service. The acquisition of the recipient's public key is outside the scope of the specification, although Section 5 defines one possible mechanism. With the public key, the originator encrypts the data encrypting key according to the Key-Info: header defined below. The complete set of headers generated by the encryption service is as follows. Version: indicates which version of the MOSS protocol the remaining headers represent and is defined in Section 2.1.2.1. DEK-Info: indicates the algorithm and mode used to encrypt the data. Crocker, et al Standards Track [Page 12]
RFC 1848 MIME Object Security Services October 1995 Recipient-ID: indicates the public key used to encrypt the data encrypting key that was used to encrypt the data. Key-Info: contains data encrypting key encrypted with the recipient's public key. Each invocation of the encryption service must emit exactly one Version: header, exactly one DEK-Info: header, and at least one pair of Recipient-ID: and Key-Info: headers. Headers are always emitted in the order indicated. The Recipient-ID: and Key-Info: headers are always emitted in pairs in the order indicated, one pair for each recipient of the encrypted data. A Key-Info: header is always interpreted in the context of the immediately preceding Recipient-ID: header. IMPLEMENTORS NOTE: Implementors should always generate a Recipient-ID: and Key-Info header pair representing the originator of the encrypted data. By doing so, if an originator sends a message to a recipient that is returned undelivered, the originator will be able to decrypt the message and determine an appropriate course of action based on its content. If not, an originator will not be able to review the message that was sent. 2.2.1.1. DEK-Info: The purpose of the data encrypting key information header is to indicate the algorithm and mode used to encrypt the data, along with any cryptographic parameters that may be required, e.g., initialization vectors. Its value is either a single argument indicating the algorithm and mode or a comma separated pair of arguments where the second argument carries any cryptographic parameters required by the algorithm and mode indicated in the first argument. The data encrypting key information header is defined by the grammar token <dekinfo> as follows. <dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF The grammar tokens for the encryption algorithm and mode identifier (<dekalgid>) and the optional cryptographic parameters (<dekparameters>) are defined by RFC 1423. They are also reprinted in Appendix B. Crocker, et al Standards Track [Page 13]
RFC 1848 MIME Object Security Services October 1995 2.2.1.2. Recipient-ID: The purpose of the recipient header is to identify the private key that must be used to decrypt the data encrypting key that will be used to decrypt the data. Presumably the recipient owns the private key and thus is less interested in identifying the owner of the key and more interested in the private key value itself. Nonetheless, the recipient header may convey either or both pieces of information: the public key corresponding to the private key to be used to decrypt the data encrypting key the name of the owner and which of the owner's private keys to use to decrypt the data encrypting key The decision as to what information to place in the value rests entirely with the originator. The suggested choice is to include just the public key. However, some recipients may prefer that originators not include their public key. How this preference is conveyed to and managed by the originator is outside the scope of this specification. The recipient header is defined by the grammar token <recipid> as follows. <recipid> ::= "Recipient-ID:" <id> CRLF The grammar token <id> is defined in Section 4. 2.2.1.3. Key-Info: The purpose of the key information header is to convey the encrypted data encrypting key. Its value is a comma separated list of two arguments: the algorithm and mode identifier in which the data encrypting key is encrypted and the encrypted data encrypting key. The key information header is defined by the grammar token <asymkeyinfo> as follows. <asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF The grammar tokens for the encryption algorithm and mode identifier (<ikalgid>) and the encrypted data encrypting key format (<asymsignmic>) are defined by RFC 1423. They are also reprinted in Appendix B. IMPLEMENTORS NOTE: RFC 1423 is referenced by the PEM protocol, which includes support for symmetric signatures and key Crocker, et al Standards Track [Page 14]
RFC 1848 MIME Object Security Services October 1995 management. As a result, some of the grammar tokens defined there, for example, <ikalgid>, will include options that are not legal for this protocol. These options must be ignored and have not been included in the appendix. 2.2.2. application/moss-keys Content Type Definition (1) MIME type name: application (2) MIME subtype name: moss-keys (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: quoted-printable is always sufficient (6) Security considerations: none The "application/moss-keys" content type is used on the first body part of an enclosing multipart/encrypted. Its content is comprised of the data encryption key used to encrypt the data in the second body part and other control information required to decrypt the data, as defined by Section 2.2.1. The label "application/moss-keys" must be used as the value of the protocol parameter of the enclosing multipart/encrypted; the protocol parameter must be present. An application/moss-keys body part is constructed as follows: Content-Type: application/moss-keys <mosskeys> where the <mosskeys> token is defined as follows. <mosskeys> ::= <version> <dekinfo> 1*<recipasymflds> <version> ::= "Version:" "5" CRLF <dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF <recipasymflds> ::= <recipid> <asymkeyinfo> <recipid> ::= "Recipient-ID:" <id> CRLF <asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF Crocker, et al Standards Track [Page 15]
RFC 1848 MIME Object Security Services October 1995 The token <id> is defined in Section 4. The token <version> is defined in Section 2.1.2.1. All other tokens are defined in Section 2.2.1.3. 2.2.3. Use of multipart/encrypted Content Type The definition of the multipart/encrypted body part in [7] specifies three steps for creating the body part. (1) The body part to be encrypted is created according to a local convention, for example, with a text editor or a mail user agent. (2) The body part is prepared for encryption according to the protocol parameter, in this case the body part must be in MIME canonical form. (3) The prepared body part is encrypted according to the protocol parameter, in this case according to Section 2.2.1. The multipart/encrypted content type is constructed as follows. (1) The value of its required parameter "protocol" is set to "application/moss-keys". (2) The first body part is labeled "application/moss-keys" and is filled with the control information generated by the encryption service. (3) The encrypted body part becomes the content of its second body part, which is labeled "application/octet-stream". A multipart/encrypted content type with the MOSS protocol might look as follows: Crocker, et al Standards Track [Page 16]
RFC 1848 MIME Object Security Services October 1995
RFC 1848 MIME Object Security Services October 1995 To: Ned Freed <ned@innosoft.com> Subject: Hi Ned! MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/moss-signature"; micalg="rsa-md5"; boundary="Signed Boundary" --Signed Boundary & Content-Type: message/rfc822 & Content-ID: <21468.785187044.2@tis.com> & & To: Ned Freed <ned@innosoft.com> & Subject: Hi Ned! & & & How do you like the new MOSS? & & Jim --Signed Boundary Content-Type: application/moss-signature Content-ID: <21468.785187044.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4f= qQ61aoC1fO6BekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8= KRGJ9wh1HU4TrghGdhn0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,= 2,galvin@tis.com MIC-Info: RSA-MD5,RSA,ctbDBgkYtFW1sisb5w4/Y/p94LftgQ0IrEn3d6WT= wjfxFBvAceVWfawsZPLijVKZUYtbIqJmjKtzTJlagBawfA/KhUsvTZdR6Dj+4G= d8dBBwMKvqMKTHAUxGXYxwNdbK --Signed Boundary-- 6.4. Encrypt Text of a Message If we choose to encrypt the text of the following message, that is, encrypt the lines marked with asterisk '*': To: Jim Galvin <galvin@tis.com> Subject: an encrypted message * How do you like the new MOSS? * * Jim Crocker, et al Standards Track [Page 33]
RFC 1848 MIME Object Security Services October 1995 the message would look as follows (note the use of the email name identifier, on the line marked with an asterisk '*'): To: Jim Galvin <galvin@tis.com> Subject: an encrypted message MIME-Version: 1.0 Content-Type: multipart/encrypted; protocol="application/moss-keys"; boundary="Encrypted Boundary" --Encrypted Boundary Content-Type: application/moss-keys Content-ID: <21535.785187667.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 DEK-Info: DES-CBC,D488AAAE271C8159 * Recipient-ID: EN,2,galvin@tis.com Key-Info: RSA,ISbC3IR01BrYq2rp493X+Dt7WrVq3V3/U/YXbxOTY5cmiy1/= 7NvSqqXSK/WZq05lN99RDUQhdNxXI64ePAbFWQ6RGoiCrRs+Dc95oQh7EFEPoT= 9P6jyzcV1NzZVwfp+u --Encrypted Boundary Content-Type: application/octet-stream Content-Transfer-Encoding: base64 AfR1WSeyLhy5AtcX0ktUVlbFC1vvcoCjYWy/yYjVj48eqzUVvGTGMsV6MdlynU d4jcJgRnQIQvIxm2VRgH8W8MkAlul+RWGu7jnxjp0sNsU562+RZr0f4F3K3n4w onUUP265UvvMj23RSTguZ/nl/OxnFM6SzDgV39V/i/RofqI= --Encrypted Boundary-- Crocker, et al Standards Track [Page 34]
RFC 1848 MIME Object Security Services October 1995 6.5. Encrypt the Signed Text of a Message If, instead, we choose to sign the text before we encrypt it, the structure would be as follows, where lines with an asterisk '*' are digitally signed and lines with an ampersand '&' are encrypted: Content-Type: multipart/encrypted; protocol="application/moss-keys"; boundary="Encrypted Boundary" --Encrypted Boundary Content-Type: application/moss-keys KEY INFORMATION --Encrypted Boundary Content-Type: application/octet-stream & Content-Type: multipart/signed; & protocol="application/moss-signature"; & micalg="rsa-md5"; boundary="Signed Boundary" & & --Signed Boundary & * Content-Type: text/plain & * & * How do you like the new MOSS? & * & * Jim & & --Signed Boundary & Content-Type: application/moss-signature & & SIGNATURE INFORMATION & & --Signed Boundary-- --Encrypted Boundary-- where KEY INFORMATION and SIGNATURE INFORMATION are descriptive of the actual content that would appear in a real body part. The actual message would be like this: Crocker, et al Standards Track [Page 35]
RFC 1848 MIME Object Security Services October 1995 To: Jim Galvin <galvin@tis.com> Subject: an encrypted message MIME-Version: 1.0 Content-Type: multipart/encrypted; protocol="application/moss-keys"; boundary="Encrypted Boundary" --Encrypted Boundary Content-Type: application/moss-keys Content-ID: <21546.785188458.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 DEK-Info: DES-CBC,11CC89F8D90F1DFE Recipient-ID: EN,2,galvin@tis.com Key-Info: RSA,AZTtlEc6xm0vjkvtVUITUh7sz+nOuOwP0tsym6CQozD9IwVIJz= Y8+vIfbh5BpR0kS6prq3EGFBFR8gRMUvbgHtEKPD/4ICQ7b6ssZ7FmKhl/cJC5rV= jpb4EOUlwOXwRZ --Encrypted Boundary Content-Type: application/octet-stream Content-Transfer-Encoding: base64 ZvWvtosDzRBXJzkDFFRb9Qjrgm2nDWg3zotJ3ZpExpWUG/aRJ7Vwd+PWkSfrDPJ5 2V/wkxwMrum6xJHZonrtyd0AvaztvriMm2zXTefzwpGG1i5zK47PBqreLA3HDTK2 U6B13vzpE8wMSVefzaCTSpXRSCh08ceVEZrIYS53/CKZV2/Sga71pGNlux8MsJpY Lwdj5Q3NKocg1LMngMo8yrMAe+avMjfOnhui49Xon1Gft+N5XDH/+wI9qxI9fkQv NZVDlWIhCYEkxd5ke549tLkJjEqHQbgJW5C+K/uxdiD2dBt+nRCXcuO0Px3yKRyY g/9BgTf36padSHuv48xBg5YaqaEWpEzLI0Qd31vAyP23rqiPhfBn6sjhQ2KrWhiF 2l3TV8kQsIGHHZUkaUbqkXJe6PEdWWhwsqCFPDdkpjzQRrTuJH6xleNUFg+CG1V+ tL4IgMjQqm3KVojRXx8bG2auVN89NfwFswmoq4fXTrh3xyVS1VgxjKkcYI8SVVmk YjCxVviJP3zO2UzBvCoMfADtBVBz1njYETtVGDO97uT39MqL85uEgiF4E5TkOj/m 04+88G0/vvN/RISKJiFQJ3FyVIB/ShX9Dixl8WCx3rxwN5g2QFLiyQVulzuNhimS D4ZxEo7smcTsAXUjwSLRtdjmTTutw2GmFESUaIrY81NcpQJRPNAvF0IkN6ddwL4q vzUS99vjQp15g9FUv82lHtHwhM18a9GokVG8xYOjBBsn9anp9abh4Tp/c/vpbunQ UqnpV29rF4wj+8OwUOMi9ymGabBXAjw7DhNH2RdRVr1upQO896OX81VWB0LsA0cp +ymxhTrEI+wCHcrsNMoRK/7zAeuAi0f1t9bN594EFlLoIrBnKEa1/OUAhMT7kG1f NkSRnc8BZswIoPyRetsTurQfD40nsVHvNwE9Jz7wbBo00gd6blPADOUYFxfW5zu6 ubygBqJiKPM4II2fCdNj7CptfQcoRTeguKMVPLVmFg/EINuWBFm10GqlYT7p4zhf zysV/3r5LVZ1E8armTCRJ2GoYG5h+SKcytaQ0IT8S2nLPCZl1hzdajsrqHFe8omQ --Encrypted Boundary-- Crocker, et al Standards Track [Page 36]
RFC 1848 MIME Object Security Services October 1995 6.6. Protecting Audio Content In addition to text, the MOSS services as defined here will protect arbitrary body parts, for example, the following audio body part: Content-Type: audio/basic AUDIO DATA HERE 6.6.1. Sign Audio Content When signed an audio content would appear as follows, where lines with an ampersand '&' are digitally signed: Content-Type: multipart/signed; protocol="application/moss-signature"; micalg="rsa-md5"; boundary="Signed Boundary" --Signed Boundary & Content-Type: audio/basic & Content-Transfer-Encoding: base64 & & base64(AUDIO-DATA-HERE) --Signed Boundary Content-Type: application/moss-signature SIGNATURE-INFORMATION-HERE --Signed Boundary-- where AUDIO-DATA-HERE and SIGNATURE-INFORMATION-HERE are descriptive of the content that would appear in a real body part. 6.6.2. Encrypt Audio Content When encrypted an audio content would appear as follows, where lines with an ampersand '&' are encrypted: Crocker, et al Standards Track [Page 37]
RFC 1848 MIME Object Security Services October 1995 Content-Type: multipart/encrypted; protocol="application/moss-keys"; boundary="Encrypted Boundary" --Encrypted Boundary Content-Type: application/moss-keys KEY-INFORMATION-HERE --Encrypted Boundary Content-Type: application/octet-stream Content-Transfer-Encoding: base64 & Content-Type: audio/basic & & base64(encrypted(AUDIO-DATA-HERE)) --Encrypted Boundary-- where KEY-INFORMATION-HERE and AUDIO-DATA-HERE are descriptive of the content that would appear in a real body part. 7. Observations The use of MIME and the framework defined by [7] exhibits several properties: (1) It allows arbitrary content types to be protected, not just the body of an RFC822 message. (2) It allows a message to contain several body parts which may or may not be protected. (3) It allows the components of a multipart or message content to be protected with different services. The use of a MIME-capable user agent makes complex nesting of protected message body parts much easier. For example, the user can separately sign and encrypt a message. This allows complete separation of the confidentiality security service from the digital signature security service. That is, different key pairs could be used for the different services and could be protected separately. Crocker, et al Standards Track [Page 38]
RFC 1848 MIME Object Security Services October 1995 This is useful for at least two reasons. First, some public key algorithms do not support both digital signatures and encryption; two key pairs would be required in this case. Second, 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. 8. Comparison of MOSS and PEM Protocols MOSS differs from PEM in the following ways. (1) When using PEM, users are required to have certificates. When using MOSS, users need only have a public/private key pair. (2) MOSS broadens the allowable name forms that users may use to identify their public keys, including arbitrary strings, email addresses, or distinguished names. (3) PEM currently only supports text-based electronic mail messages and the message text is required to be represented by the ASCII character set with "<CR><LF>" line delimiters. These restrictions no longer apply. (4) 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 in any order according to the needs of the requesting application. (5) MIME includes transfer encoding operations to ensure the unmodified transfer of body parts. Therefore, unlike PEM, MOSS does not need to include these functions. (6) 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 includes a decimal number that is 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 Crocker, et al Standards Track [Page 39]
RFC 1848 MIME Object Security Services October 1995 specified in this document. (7) 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. (8) 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: application/mosskey- request and application/mosskey-data. (9) The header fields having to do with certificates (Originator- Certificate: and Issuer-Certificate:) and CRLs (CRL:) are relegated for use only in the application/mosskey-data and application/mosskey-request content types and are no longer allowed in the header portion of a PEM signed or encrypted message. This separates key management services from the digital signature and encryption services. (10) 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 disallow the functionality of combinations of encryption and signature security found in [3]. (11) 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. (12) 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 management, there is no requirement in that case to include an Originator-ID field. (13) The protocol specified here explicitly excludes symmetric key Crocker, et al Standards Track [Page 40]
RFC 1848 MIME Object Security Services October 1995 management. (14) This document requires all data that is to be digitally signed to be represented in 7bit form. 9. Security Considerations This entire document is about security. 10. Acknowledgements David H. Crocker suggested the use of a multipart structure for the MIME and PEM interaction, which has evolved into the MOSS protocol. The MOSS protocol is a direct descendant of the PEM protocol. The authors gratefully acknowledge the editors of those specification, especially John Linn and Steve Kent. This work would not have been possible had it not been for all of the PEM developers, users, and interested persons who are always present on the PEM developers mailing list and at PEM working group meetings at IETF meetings, especially, Amanda Walker, Bob Juenemann, Steve Dusse, Jeff Thomson, and Rhys Weatherly. 11. References [1] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, University of Delaware, August 1982. [2] Borenstein, N., and N. 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. [3] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG, February 1993. [4] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, BBN Communications, February 1993. [5] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, Trusted Information Systems, February 1993. Crocker, et al Standards Track [Page 41]
RFC 1848 MIME Object Security Services October 1995 [6] Kaliski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services", RFC 1424, RSA Laboratories, February 1993. [7] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Trusted Information Systems and Innosoft, September 1995 [8] The Directory -- Models. X.501, 1988. Developed in collaboration, and technically aligned, with ISO 9594-2. [9] The Directory -- Authentication Framework. X.509, 1988. Developed in collaboration, and technically aligned, with ISO 9594-8. Crocker, et al Standards Track [Page 42]
RFC 1848 MIME Object Security Services October 1995 12. Authors' Addresses Steve Crocker CyberCash, Inc. 2086 Hunters Crest Way Vienna, VA 22181 Phone: +1 703 620 1222 Fax: +1 703 391 2651 EMail: crocker@cybercash.com James M. Galvin Trusted Information Systems 3060 Washington Road Glenwood, MD 21738 Phone: +1 301 854 6889 Fax: +1 301 854 5363 EMail: galvin@tis.com Sandra Murphy Trusted Information Systems 3060 Washington Road Glenwood, MD 21738 Phone: +1 301 854 6889 Fax: +1 301 854 5363 EMail: murphy@tis.com Ned Freed Innosoft International, Inc. 1050 East Garvey Avenue South West Covina, CA 91790 Phone: +1 818 919 3600 Fax: +1 818 919 3614 EMail: ned@innosoft.com Crocker, et al Standards Track [Page 43]
RFC 1848 MIME Object Security Services October 1995 Appendix A: Collected Grammar The version of the grammar in this document is as follows: <version> ::= "Version:" "5" CRLF The following grammar tokens are used throughout this specification: <encbin> ::= 1*<encbingrp> <encbingrp> ::= 4*4<encbinchar> <encbinchar> ::= <ALPHA> / <DIGIT> / "+" / "/" / "=" <hexchar> ::= <DIGIT> / "A" / "B" / "C" / "D" / "E" / "F" ; no lower case The content of an application/moss-signature body part is as follows: <mosssig> ::= <version> ( 1*<origasymflds> ) <version> ::= "Version:" "5" CRLF <origasymflds> ::= <origid> <micinfo> <origid> ::= "Originator-ID:" <id> CRLF <micinfo> ::= "MIC-Info:" <micalgid> "," <ikalgid> "," <asymsignmic> CRLF The content of an application/moss-keys body part is as follows: <mosskeys> ::= <version> <dekinfo> 1*<recipasymflds> <version> ::= "Version:" "5" CRLF <dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF <recipasymflds> ::= <recipid> <asymkeyinfo> <recipid> ::= "Recipient-ID:" <id> CRLF <asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF Crocker, et al Standards Track [Page 44]
RFC 1848 MIME Object Security Services October 1995 Identifiers are defined as follows: <id> ::= <id-subset> / <id-publickey> / <id-issuer> <id-subset> ::= <id-email> / <id-string> / <id-dname> <id-email> ::= "EN" "," <keysel> "," <emailstr> CRLF <id-string> ::= "STR" "," <keysel> "," <string> CRLF <id-dname> ::= "DN" "," <keysel> "," <dnamestr> CRLF <id-publickey> ::= "PK" "," <publickey> [ "," <id-subset> ] CRLF <id-issuer> ::= "IS" "," <dnamestr> "," <serial> CRLF <keysel> ::= 1*<hexchar> ; hex dump of a non-null sequence of octets <emailstr> ::= <addr-spec> / <route-addr> ; an electronic mail address as defined by ; these two tokens from RFC822 <string> ::= ; a non-null sequence of characters <dnamestr> ::= <encbin> ; a printably encoded, ASN.1 encoded ; distinguished name (as defined by the 'Name' ; production specified in X.501 [8]) <publickey> ::= <encbin> ; a printably encoded, ASN.1 encoded public ; key (as defined by the ; 'SubjectPublicKeyInfo' production specified ; in X.509 [9]) <serial> ::= 1*<hexchar> ; hex dump of a certificate serial number The content of an application/mosskey-request body part is as follows: <request> ::= <version> ( <subject> / <issuer> / <certification> ) <version> ::= "Version:" "5" CRLF Crocker, et al Standards Track [Page 45]
RFC 1848 MIME Object Security Services October 1995 <subject> ::= "Subject:" <id> CRLF <issuer> ::= "Issuer:" <id> CRLF <certification> ::= "Certification:" <encbin> CRLF The content of an application/mosskey-data body part is as follows: <mosskeydata> ::= <version> ( <publickeydata> / <certchain> / <crlchain> ) <version> ::= "Version:" "5" CRLF <publickeydata> ::= "Key:" "PK" "," <publickey> "," <id-subset> CRLF <certchain> ::= <cert> *( [ <crl> ] <cert> ) <crlchain> ::= 1*( <crl> [ <cert> ] ) <cert> ::= "Certificate:" <encbin> CRLF <crl> ::= "CRL:" <encbin> CRLF Crocker, et al Standards Track [Page 46]
RFC 1848 MIME Object Security Services October 1995 Appendix B: Imported Grammar Options normally present in the grammar reprinted here which are illegal in MOSS are excluded in this reprinting, for the convenience of the reader. 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> ::= "RSA" <micalgid> ::= "RSA-MD2" / "RSA-MD5" <dekparameters> ::= <DESCBCparameters> <DESCBCparameters> ::= <IV> <IV> ::= <hexchar16> <hexchar16> ::= 16*16<hexchar> <asymsignmic> ::= <RSAsignmic> <RSAsignmic> ::= <encbin> <asymencdek> ::= <RSAencdek> <RSAencdek> ::= <encbin> The following productions are taken from [1]. The grammar presented in [1] remains the authoritative source for these productions; they are repeated here for the convenience of the reader. <route-addr> ::= "<" [ <route> ] <addr-spec> ">" <route> ::= 1# ( "@" <domain> ) ":" ; path-relative <addr-spec> ::= <local-part> "@" <domain>; global address <local-part> ::= <word> *( "." <word> ) ; uninterpreted ; case-preserved <domain> ::= <sub-domain> *( "." <sub-domain> ) <sub-domain> ::= <domain-ref> / <domain-literal> <domain-ref> ::= <atom> ; symbolic ; reference <domain-literal>::= "[" *( <dtext> / <quoted-pair> ) "]" Crocker, et al Standards Track [Page 47]
RFC 1848 MIME Object Security Services October 1995 <dtext> ::= <any CHAR excluding "[", "]", "\" & <CR>, & including linear-white-space> ; => may be folded <word> ::= <atom> / <quoted-string> <quoted-string> ::= """ *( <qtext> / <quoted-pair> ) """ <qtext> ::= (any <CHAR> excepting """, "\", and CR, and including <linear-white-space>) <quoted-pair> ::= "\" <CHAR> ; may quote any ; char <linear-white-space> ::= 1*( [ CRLF ] <LWSP-char> ) ; semantics = SPACE ; CRLF => folding <LWSP-char> ::= SPACE / HTAB ; semantics = SPACE <atom> ::= 1*(any <CHAR> except <specials>, SPACE and <CTL>s) <CHAR> ::= <any ASCII character> <CTL> ::= <any ASCII control character and DEL> <specials> ::= "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> / "." / "[" / "]" ; Must be in quoted- ; string, to use ; within a word. <ALPHA> ::= <any ASCII alphabetic character> ; (101-132, 65.-90.) ; (141-172, 97.-122.) <DIGIT> ::= <any ASCII decimal digit>; (60-71, 48.-57.)



Back to RFC index

 

Associates:

 



Sponsered-Sites:

Register domain name and transfer | Cheap webhosting service | Domain name registration

 

 

""