diff options
Diffstat (limited to 'doc/rfc/rfc1848.txt')
| -rw-r--r-- | doc/rfc/rfc1848.txt | 2691 |
1 files changed, 2691 insertions, 0 deletions
diff --git a/doc/rfc/rfc1848.txt b/doc/rfc/rfc1848.txt new file mode 100644 index 0000000..2cfe325 --- /dev/null +++ b/doc/rfc/rfc1848.txt @@ -0,0 +1,2691 @@ + + + + + + +Network Working Group S. Crocker +Request For Comments: 1848 CyberCash, Inc. +Category: Standards Track N. Freed + Innosoft International, Inc. + J. Galvin + S. Murphy + Trusted Information Systems + October 1995 + + + MIME Object Security Services + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document defines MIME Object Security Services (MOSS), a + protocol that uses the multipart/signed and multipart/encrypted + framework [7] to apply digital signature and encryption services to + MIME objects. The services are offered through the use of end-to-end + cryptography between an originator and a recipient at the application + layer. Asymmetric (public key) cryptography is used in support of + the digital signature service and encryption key management. + Symmetric (secret key) cryptography is used in support of the + encryption service. The procedures are intended to be compatible + with a wide range of public key management approaches, including both + ad hoc and certificate-based schemes. Mechanisms are provided to + support many public key management approaches. + +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 + + + Content-Type: multipart/encrypted; + protocol="application/moss-keys"; + boundary="Encrypted Message" + + --Encrypted Message + Content-Type: application/moss-keys + + Version: 5 + DEK-Info: DES-CBC,DEK-INFORMATION + Recipient-ID: ID-INFORMATION + Key-Info: RSA,KEY-INFORMATION + + --Encrypted Message + Content-Type: application/octet-stream + + ENCRYPTED-DATA + --Encrypted Message-- + + where DEK-INFORMATION, ID-INFORMATION, and KEY-INFORMATION are + descriptive of the content that would appear in a real body part. + +3. Removing MIME Object Security Services + + The verification of the MOSS digital signature service requires the + following components. + + + (1) A recipient to verify the digital signature. + + + (2) A multipart/signed body part with two body parts: the signed + data and the control information. + + + (3) The public key of the originator. + + + The signed data and control information of the enclosing + multipart/signed are prepared according to the description below. + The digital signature is verified by re-computing the hash of the + data, decrypting the hash value in the control information with the + originator's public key, and comparing the two hash values. If the + two hash values are equal, the signature is valid. + + The decryption of the MOSS encryption service requires the following + components. + + + + + +Crocker, et al Standards Track [Page 17] + +RFC 1848 MIME Object Security Services October 1995 + + + (1) A recipient to decrypt the data. + + + (2) A multipart/encrypted body part with two body parts: the + encrypted data and the control information. + + + (3) The private key of the recipient. + + + The encrypted data and control information of the enclosing + multipart/encrypted are prepared according to the description below. + The data encrypting key is decrypted with the recipient's private key + and used to decrypt the data. + + The next two sections describe the digital signature and encryption + services in detail, respectively. + +3.1. Digital Signature Service + + This section describes the processing steps necessary to verify the + MOSS digital signature service. The definition of the + multipart/signed body part in [7] specifies three steps for receiving + it. + + + (1) The digitally signed body part and the control information body + part are prepared for processing. + + + (2) The prepared body parts are made available to the digital + signature verification process. + + + (3) The results of the digital signature verification process are + made available to the user and processing continues with the + digitally signed body part, as returned by the digital signature + verification process. + + + Each of these steps is described below. + +3.1.1. Preparation + + The digitally signed body part (the data) and the control information + body part are separated from the enclosing multipart/signed body + part. + + + + +Crocker, et al Standards Track [Page 18] + +RFC 1848 MIME Object Security Services October 1995 + + + The control information is prepared by removing any content transfer + encodings that may be present. + + The digitally signed body part is prepared by leaving the content + transfer encodings intact and canonicalizing the line delimiters + according to Step 2 of Section 2.1.1. + +3.1.2. Verification + + First, the recipient must obtain the public key of the originator. + The public key may be contained in the control information or it may + be necessary for the recipient to retrieve the public key based on + information present in the control information. The retrieval may be + from a local database or from a remote service. The acquisition of + the originator's public key is outside the scope of the + specification, although Section 5 defines one possible mechanism. + + With the public key, the recipient decrypts the hash value contained + in the control information. Then, a new hash value is computed over + the body part purported to have been digitally signed. + + Finally, the two hash values are compared to determine the accuracy + of the digital signature. + +3.1.3. Results + + There are two required components of the results of the verification + process. The first is an indication as to whether a public key could + be found that allows the hash values in the previous step to compare + equal. Such an indication verifies only that the data received is + the same data that was digitally signed. + + The second indication identifies the owner of the public key who is + presumably the holder of the private key that created the digital + signature. The indication must include a testament as to the + accuracy of the owner identification. + + At issue is a recipient knowing who created the digital signature. + In order for the recipient to know with certainty who digitally + signed the message, the binding between the owner's name and the + public key must have been verified by the recipient prior to the + verification of the digital signature. The verification of the + binding may have been completed offline and stored in a trusted, + local database or, if the owner's name and public key are embodied in + a certificate, it may be possible to complete it in realtime. See + Section 5 for more information. + + + + + +Crocker, et al Standards Track [Page 19] + +RFC 1848 MIME Object Security Services October 1995 + + +3.2. Encryption Service + + This section describes the processing steps necessary to decrypt the + MOSS encryption service. The definition of the multipart/encrypted + body part in [7] specifies three steps for receiving it. + + + (1) The encrypted body part and the control information body part + are prepared for processing. + + + (2) The prepared body parts are made available to the decryption + process. + + + (3) The results of the decryption process are made available to the + user and processing continues with the decrypted body part, as + returned by the decryption process. + + + Each of these steps is described below. + +3.2.1. Preparation + + The encrypted body part (the data) and the control information body + part are separated from the enclosing multipart/encrypted body part. + The body parts are prepared for the decryption process by removing + any content transfer encodings that may be present. + +3.2.2. Decryption + + First, the recipient must locate the encrypted data encrypting key in + the control information. Each Recipient-ID: header is checked in + order to see if it identifies the recipient or a public key of the + recipient. + + If it does, the immediately following Key-Info: header will contain + the data encrypting key encrypted with the public key of the + recipient. The recipient must use the corresponding private key to + decrypt the data encrypting key. + + The data is decrypted with the data encrypting key. The decrypted + data will be a MIME object, a body part, ready to be processed by a + MIME agent. + + + + + + + +Crocker, et al Standards Track [Page 20] + +RFC 1848 MIME Object Security Services October 1995 + + +3.2.3. Results + + If the recipient is able to locate and decrypt a data encrypting key, + from the point of view of MOSS the decryption should be considered + successful. An indication of the owner of the private key used to + decrypt the data encrypting key must be made available to the user. + + Ultimately, the success of the decryption is dependent on the ability + of a MIME agent to continue processing with the decrypted body part. + +4. Identifying Originators, Recipients, and Their Keys + + In the PEM specifications, public keys are required to be embodied in + certificates, an object that binds each public key with a + distinguished name. A distinguished name is a name form that + identifies the owner of the public key. The embodiment is issued by + a certification authority, a role that is expected to be trustworthy + insofar as the certification authority would have procedures to + verify the identity of the owner prior to issuing the certificate. + + In MOSS, a user is not required to have a certificate. The MOSS + services require that the user have at least one public/private key + pair. The MOSS protocol requires the digital signature and + encryption services to emit Originator-ID: and Recipient-ID: headers, + as appropriate. In the discussion above the actual value of these + headers was omitted, having been relegated to this section. Although + the value of each of these headers serves a distinct purpose, for + simplicity the single grammar token <id> represents the value that + may be assigned to either header. + + One possible value for the Originator-ID: and Recipient-ID: headers + is the public key values themselves. However, while it is true that + the public keys alone could be exchanged and used by users to + communicate, the values are, in fact, large and cumbersome. In + addition, public keys would appear as a random sequence of characters + and, as a result, would not be immediately consumable by human users. + + NOTE: It should be pointed out that a feature of being able to + specify the public key explicitly is that it allows users to + exchange encrypted, anonymous mail. In particular, receiving + users will always know a message comes from the same originating + user even if the real identity of the originating user is unknown. + + Recognizing that the use of public keys is, in general, unsuitable + for use by humans, MOSS allows other identifiers in Originator-ID: + and Recipient-ID: headers. These other identifiers are comprised of + two parts: a name form and a key selector. + + + + +Crocker, et al Standards Track [Page 21] + +RFC 1848 MIME Object Security Services October 1995 + + + The name form is chosen and asserted by the user who owns the + public/private key pair. Three name forms are specified by this + document. The use of a distinguished name is retained for + compatibility with PEM (and compatibility with the X.500 Directory + should it become a ubiquitous service). However, the Internet + community has a great deal of experience with the use of electronic + mail addresses as a name form. Also, arbitrary strings are useful to + identify the owners of public keys when private name forms are used. + Hence, email addresses and arbitrary strings are included as name + forms to increase flexibility. + + Since a user may have more than one public key and may wish to use + the same name form for each public key, a name form is insufficient + for uniquely identifying a public key. A unique "key selector" must + be assigned to each public key. The combination of a name form and + the key selector uniquely identifies a public key. Throughout this + document, this combination is called an identifier. There are 5 + identifiers specified by this document. + + NOTE: In the simplest case, key selectors will be assigned by the + owners of the public/private key pairs. This works best when + users generate their own key pairs for personal use, from which + they distribute their public key to others asserting by + declaration that the public key belongs to them. When the + assertion that the public key belongs to them is made by a third + party, for example when a certification authority issues a + certificate to a user according to [4], the key selector may be + assigned by that third party. + + The value of the key selector must be unique with respect to the name + form with which it forms an identifier. Although the same key + selector value may be used by more than one name form it must not be + used for two different keys with the same name form. When considered + separately, neither a name form nor a key selector is sufficient for + identifying the public key to be used. Either could be used to + determine a set of public keys that may be tried in turn until the + desired public key is identified. + + With a public/private key pair for one's self and software that is + MOSS aware, an originating user may digitally sign arbitrary data and + send it to one or more recipients. With the public keys of the + recipients, a user may encrypt the data so that only the intended + recipients can decrypt and read it. With the name forms assigned to + the public keys, originators and recipients can easily recognize + their peers in a communication. + + In the next section the 3 name forms are described in detail. + Following that is the specification of the 5 identifiers. + + + +Crocker, et al Standards Track [Page 22] + +RFC 1848 MIME Object Security Services October 1995 + + +4.1. Name Forms + + There are 3 name forms specified by this document: email addresses, + distinguished names, and arbitrary strings. + +4.1.1. Email Addresses + + The email address (grammar token <emailstr>) used must be a valid + RFC822 address, which is defined in terms of one of the two grammar + tokens <addr-spec> or <route-addr>. The grammar for these two tokens + is included in the Appendix as a convenience; the definitive source + for these tokens is necessarily RFC822 [1]. + + <emailstr> ::= <addr-spec> / <route-addr> + ; an electronic mail address as defined by + ; one of these two tokens from RFC822 + + For example, the strings "crocker@tis.com", "galvin@tis.com", + "murphy@tis.com", and "ned@innosoft.com" are all email addresses. + +4.1.2. Arbitrary Strings + + The arbitrary string (grammar token <string>) must have a length of + at least 1. There are no other restrictions on the value chosen. + + <string> ::= ; a non-null sequence of characters + + For example, the string + + the SAAG mailing list maintainer + + is an arbitrary string. + +4.1.3. Distinguished Names + + The distinguished name (grammar token <dnamestr>) must be constructed + according to the guidelines of the X.500 Directory. The actual + syntax of the distinguished name is outside the scope of this + specification. However, RFC1422, for example, specifies syntactic + restrictions based on its choice of a certification hierarchy for + certificates. + + For the purposes of conveying a distinguished name from an originator + to a recipient, it must be ASN.1 encoded and then printably encoded + according to the base64 encoding defined by MIME. + + + + + + +Crocker, et al Standards Track [Page 23] + +RFC 1848 MIME Object Security Services October 1995 + + + <dnamestr> ::= <encbin> + ; a printably encoded, ASN.1 encoded + ; distinguished name (as defined by the 'Name' + ; production specified in X.501 [8]) + + For example, + + /Country Name=US + /State or Province Name=MD + /Organization Name=Trusted Information Systems + /Organizational Unit Name=Glenwood + /Common Name=James M. Galvin/ + + is a distinguished name in a user friendly format (line breaks and + leading spaces present only to improve readability). When encoded, + it would appear as follows (line breaks present only to improve + readability): + + MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3RlZCBJ + bmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1UEAxMP + SmFtZXMgTS4gR2Fsdmlu + +4.2. Identifiers + + There are 5 types of identifiers specified by this document: + + email address identifiers + + arbitrary string identifiers + + distinguished name identifiers + + the public keys themselves + + issuer name serial number pairs from a certificate + + All of these have approximately the same structure (except issuer + name and serial number which has 'TYPE, STRING, KEYSEL' for + historical reasons): + + TYPE, KEYSEL, STRING + + The TYPE field is a literal string chosen from the set "EN", "STR", + "DN", "PK", and "IS", one for each of the possible identifiers. + + The KEYSEL field is used to distinguish between the multiple public + keys that may be associated with the name form in the STRING field. + Its value must be unique with respect to all other key selectors used + + + +Crocker, et al Standards Track [Page 24] + +RFC 1848 MIME Object Security Services October 1995 + + + with the same name form. An example would be to use a portion (low- + order 16 or 32 bits) or all of the actual public key used. + + The STRING field is the name form and has a different syntax + according to the value of the TYPE field. + + The identifier used in each of the originator and recipient fields is + described by the following grammar. The definition of the key + selector token is included here since it used by several of the + identifiers below. + + <id> ::= <id-email> / <id-string> / <id-dname> + / <id-publickey> / <id-issuer> + + <keysel> ::= 1*<hexchar> + ; hex dump of a non-null sequence of octets + + Each of the identifier name forms is described below. + +4.2.1. Email Address + + The email address identifier has the following syntax. + + <id-email> ::= "EN" "," <keysel> "," <emailstr> CRLF + + The syntax of the token <emailstr> is defined in Section 4.1.1. + + For example: + + EN,1,galvin@tis.com + + is an email address identifier. + +4.2.2. Arbitrary String + + The arbitrary string identifier has the following syntax. + + <id-string> ::= "STR" "," <keysel> "," <string> CRLF + + The syntax of the token <string> is defined in Section 4.1.2. + + For example: + + STR,1,The SAAG mailing list maintainer + + is an arbitrary string identifier. + + + + + +Crocker, et al Standards Track [Page 25] + +RFC 1848 MIME Object Security Services October 1995 + + +4.2.3. Distinguished Name + + The distinguished name identifier has the following syntax. + + <id-dname> ::= "DN" "," <keysel> "," <dnamestr> CRLF + + The syntax of the token <dnamestr> is defined in Section 4.1.3. + + For example (line breaks present only to improve readability): + + DN,1,MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3R + lZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1U + EAxMPSmFtZXMgTS4gR2Fsdmlu + + is a distinguished name identifier. + +4.2.4. Public Key + + The public key identifier has the following syntax. + + <id-publickey> ::= "PK" "," <publickey> [ "," <id-subset> ] CRLF + + <publickey> ::= <encbin> + ; a printably encoded, ASN.1 encoded public + ; key (as defined by the + ; 'SubjectPublicKeyInfo' production specified + ; in X.509 [9]) + + <id-subset> ::= <id-email> / <id-string> / <id-dname> + + The production SubjectPublicKeyInfo is imported from the X.500 + Directory from the certificate object. It is currently the best + choice for a general purpose public key encoding. + + For example, (line breaks present only to improve readability): + + PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6BekJmG + 4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn + 0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB + + is a public key identifier without the optional <id-subset>. + + In normal usage, the token <id-subset> is expected to be present. It + represents a mechanism by which an identifier (name form and key + selector) can be associated with a public key. Recipients of a + public key identifier must take care to verify the accuracy of the + purported association. If they do not, it may be possible for a + malicious originator to assert an identifier that accords the + + + +Crocker, et al Standards Track [Page 26] + +RFC 1848 MIME Object Security Services October 1995 + + + originator unauthorized privileges. See Section 5.2 for more + details. + + For example, (line breaks present only to improve readability): + + PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6BekJmG + 4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn + 0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,galvin@tis.com + + is a public key identifier with the optional <id-subset>. + +4.2.5. Issuer Name and Serial Number + + The issuer name and serial number identifier has the following + syntax. + + <id-issuer> ::= "IS" "," <dnamestr> "," <serial> CRLF + + <serial> ::= 1*<hexchar> + ; hex dump of a certificate serial number + + The <id-issuer> identifier is included for compatibility with the + ID-ASymmetric fields defined in [3] (and compatibility with X.500 + Directory certificates should they become ubiquitously available). + Its syntax was chosen such that the older fields are easily converted + to this new form by prefixing the old value with "IS" (and replacing + the field name of [3] with an appropriate new ID field name). For + example, (line breaks present only to improve readability): + + IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3 + RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02 + + is an issuer name and serial number identifier according to MOSS, + while + + MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3 + RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02 + + is an issuer name and serial number identifier according to PEM. + +5. Key Management Content Types + + This document defines two key management content types: one for + requesting cryptographic key material and one for sending + cryptographic key material. Since MOSS depends only on the existence + of public/private key pairs, these content types provide a means for + conveying public keys and an assertion as to the identity of the + owner. In addition, in order to be compatible with the certificate- + + + +Crocker, et al Standards Track [Page 27] + +RFC 1848 MIME Object Security Services October 1995 + + + base key management system proposed by RFC 1422, the content types + may also be used to convey certificate and certificate revocation + list material. + + The functions defined here are based on the exchange of body parts. + In particular, a user would send a message containing at least one + application/mosskey-request content, as defined below. In response, + a user would expect to receive a message containing at least one + application/mosskey-data content, as defined below. MIME provides a + convenient framework for a user to send several request body parts + and to receive several data (response) body parts in one message. + +5.1. application/mosskey-request Content Type Definition + + (1) MIME type name: application + + (2) MIME subtype name: mosskey-request + + (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. + + <request> ::= <version> + ( <subject> / <issuer> / <certification> ) + + <version> ::= "Version:" "5" CRLF + + <subject> ::= "Subject:" <id> CRLF + + <issuer> ::= "Issuer:" <id> CRLF + + <certification> ::= "Certification:" <encbin> CRLF + + A user would use this content type to specify needed cryptographic + key information. The message containing this content type might be + directed towards an automatic or manual responder, which may be + mail-based, depending on the local implementation and environment. + The application/mosskey-request content type is an independent body + part because it is entirely independent of any other body part. + + + + + +Crocker, et al Standards Track [Page 28] + +RFC 1848 MIME Object Security Services October 1995 + + + If the application/mosskey-request 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 (CRL) chain beginning with the CRL of + the issuer identified in the field value. If the content contains a + Subject: field it requests either the public key of the subject or a + certificate chain beginning with the subject identified in the field + value, or both if both exist. + + The Subject: and Issuer: fields each contain a value of type <id>, + which is defined in Section 4. + + One possible response to receiving an application/mosskey-request + body part is to construct and return an application/mosskey-data body + part. When returning public keys, certificate chains, and + certificate revocation list chains, if there exists more than one, + several application/mosskey-data body parts are to be returned in the + reply message, one for each. + +5.2. application/mosskey-data Content Type Definition + + The principal objective of this content type is to convey + cryptographic keying material from a source to a destination. This + might be in response to the receipt of an application/mosskey-request + content type or it might be in anticipation of receiving an + application/mosskey-request if it is not sent, e.g., it may be + combined with a multipart/signed object by an originator to ensure + that a recipient has the cryptographic keying material necessary to + verify the signature. When combined with other content types, the + processing by a recipient is enhanced if the application/mosskey-data + content type is positioned in its enclosing content type prior to the + content types that will make use of its cryptographic keying + material. + + However, no explicit provision is made in this document for + determining the authenticity or accuracy of the data being conveyed. + In particular, when a public key and its identifier is conveyed, + there is nothing to prevent the source or an interloper along the + path from the source to the destination from substituting alternate + values for either the public key or the identifier. + + It is incumbent upon a recipient to verify the authenticity and + accuracy of the data received in this way prior to its use. This + problem can be addressed by the use of certificates, since a + certification hierarchy is a well-defined mechanism that conveniently + supports the automatic verification of the data. Alternatively, the + source of the application/mosskey-data body part could digitally sign + it. In this way, if the destination believes that a correct source's + + + +Crocker, et al Standards Track [Page 29] + +RFC 1848 MIME Object Security Services October 1995 + + + public key is available locally and if the destination believes the + source would convey accurate data, then the contents of the + application/mosskey-data from the source could be believed to be + accurate. + + NOTE: Insofar as a certificate represents a mechanism by which a + third party vouches for the binding between a name and a public + key, the signing of an application/mosskey-data body part is a + similar mechanism. + + (1) MIME type name: application + + (2) MIME subtype name: mosskey-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. + + <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 + + This content type is used to transfer public keys, certificate + chains, or Certificate Revocation List (CRL) chains. The information + in the body part is entirely independent of any other body part. + (Note that the converse is not true: the validity of a protected body + part cannot be determined without the proper public keys, + certificates, or current CRL information.) As such, the + application/mosskey-data content type is an independent body part. + + + +Crocker, et al Standards Track [Page 30] + +RFC 1848 MIME Object Security Services October 1995 + + + The <publickeydata> production contains exactly one public key. It + is used to bind a public key with its corresponding name form and key + selector. It is recommended that when responders are returning this + information that the enclosing body part be digitally signed by the + responder in order to protect the information. The <id-subset> token + is defined in Section 4.2.4. + + The <certchain> production contains one certificate chain. A + certificate chain starts with the requested 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. + + The relationship between a certificate and an immediately preceding + CRL is the same in both <certchain> and <crlchain>. In a <certchain> + the CRLs are optional. In a <crlchain> the certificates are + optional. + +6. Examples + + Each example is included as a separate section for ease of reference. + +6.1. Original Message Prepared for Protection + + Except as explicitly indicated, the following message is used as the + message to be protected. + + To: Ned Freed <ned@innosoft.com> + Subject: Hi Ned! + + How do you like the new MOSS? + + Jim + + + + + + + + +Crocker, et al Standards Track [Page 31] + +RFC 1848 MIME Object Security Services October 1995 + + +6.2. Sign Text of Original Message + + When the text of the original message is signed, it will look like + this, where lines with an ampersand '&' are digitally signed (note + the use of the public key identifier with the included email name + identifier, on the lines marked with an asterisk '*'): + + 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: text/plain; charset="us-ascii" + & Content-ID: <21436.785186814.2@tis.com> + & + & How do you like the new MOSS? + & + & Jim + + --Signed Boundary + Content-Type: application/moss-signature + Content-ID: <21436.785186814.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,PnEvyFV3sSyTSiGh/HFgWUIFa22jbHoTrFIMVERf= + MZXUKzFsHbmKtIowJlJR56OoImo+t7WjRfzpMH7MOKgPgzRnTwk0T5dOcP/lfb= + sOVJjleV7vTe9yoNp2P8mi/hs7 + + --Signed Boundary-- + +6.3. Sign Headers and Text of Original Message + + If, instead, we choose to protect the headers with the text of the + original message, it will look like this, where lines with an + ampersand '&' are encrypted: + + + + + + + + +Crocker, et al Standards Track [Page 32] + +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.) + + + + + + + + + +Crocker, et al Standards Track [Page 48] + |