doc: Add RFC documents

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]
+