view Side-By-Side changes

Date: Tue, 09 Apr 2002 06:10:18 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 22 Nov 1994 23:00:00 GMT
ETag: "304ba0-f841-2ed277f0"
Accept-Ranges: bytes
Content-Length: 63553
Connection: close
Content-Type: text/plain





Network Working Group                                       Steve                                         S. Crocker
INTERNET DRAFT                                                  Ned
Request For Comments: 1848                               CyberCash, Inc.
Category: Standards Track                                       N. Freed
draft-ietf-pem-mime-07.txt                                     Jim
                                            Innosoft International, Inc.
                                                               J. Galvin
                                                             Sandy
                                                               S. Murphy
                                                            November 1994


                     PEM
                                             Trusted Information Systems
                                                            October 1995


                     MIME Object Security Services and MIME

Status of this Memo

   This document is specifies an Internet Draft.  Internet Drafts are working
documents of standards track protocol for the
   Internet Engineering Task Force (IETF), its Areas, community, and
its Working Groups.  Note that other groups may also distribute working
documents as Internet Drafts.

Internet Drafts are valid for a maximum of six months requests discussion and may be
updated, replaced, or obsoleted by other documents at any time.  It is
inappropriate to use Internet Drafts as reference material or suggestions for
   improvements.  Please refer to cite
them other than as ``work in progress''.

To learn the current status edition of any Internet Draft, please check the
1id-abstracts.txt listing contained in one of "Internet
   Official Protocol Standards" (STD 1) for the Internet Drafts Shadow
Directories on ds.internic.net (US East Coast), venera.isi.edu (US West
Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe). standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document specifies how the services of defines MIME and PEM can be used in Object Security Services (MOSS), a complementary fashion.  MIME, an acronym for "Multipurpose Internet
Mail Extensions", defines the format of
   protocol that uses the contents of Internet mail
messages and provides for multi-part textual multipart/signed and non-textual message
bodies.  PEM, an acronym for "Privacy Enhanced Mail", provides message
authentication/integrity multipart/encrypted
   framework [7] to apply digital signature and message encryption services for Internet
mail messages.

An Internet electronic mail message consists of two parts: to
   MIME objects.  The services are offered through the headers use of end-to-end
   cryptography between an originator and the body.  The headers form a collection of field/value pairs
structured according to RFC822 [1], whilst the body, if structured, is
defined according to MIME [2].  MIME does not provide for recipient at the application
   layer.  Asymmetric (public key) cryptography is used in support of security services.







Crocker/Freed/Galvin/Murphy  Expires: May 1995                  [Page 1]

INTERNET DRAFT                PEM
   the digital signature service and MIME                 November 1994


PEM [3-6] specifies how to apply encryption and authentication/integrity
services to the contents key management.
   Symmetric (secret key) cryptography is used in support of a textual electronic mail message but does
not provide message structuring or type labelling facilities.  This
document specifies how the
   encryption service.  The procedures are intended to use PEM 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 and
multipart/encrypted MIME content types 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 provide
authentication/integrity
        "application/moss-signature".


   (2)  The signed body part becomes its first body part.


   (3)  Its second body part is labeled "application/moss-signature" and encryption services.  We refer to
        is filled with the control information generated by the
authentication/integrity service as a digital
        signature service.

This document specifies a number


   (4)  The value of changes its required parameter "micalg" is set to the message encryption
and signature procedures of PEM and broadens the name forms that may be same
        value used to identify public keys.  Many of the changes represent a departure in mechanism, not the MIC-Info: header in effect.

1.  Introduction

This document updates the message encryption and signature procedures
defined by [3] and replaces control information.
        If there is more than one MIC-Info: header present the key certification and related services
defined by [6].  The changes value is
        set to [3] include the separation a comma separated list of values from the
encryption and signature services, the removal MIC-Info
        headers.  The interpretation of the limitation to
enhance only text-based messages, the removal order of the transfer encoding
operation, the deprecation list of values
        is outside the Content-Domain: and Proc-Type:
headers, and the separation scope of certificate and certificate revocation
list transmission from the security enhancements.  These changes
represent a departure in mechanism, not in effect, and are detailed in
Section 8.

In addition, this document specifies four technical changes to PEM:
symmetric key management in [3] 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 deprecated, 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 canonicalization
operation
   content that would appear in [3] 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 generalized, created according to a local
   convention and then made available to the allowable name forms for encryption service.



Crocker, et al              Standards Track                    [Page 11]

RFC 1848             MIME Object Security Services          October 1995


   The following sequence of steps comprises the
identification application of public keys is broadened the
   encryption service.


   (1)  The body part to include arbitrary strings
and email addresses, and users may distribute their public keys directly be encrypted must be in lieu of certificates. MIME canonical form.


   (2)  The data encrypting key certification and related services are replaced by the
specification of two new other control information must be
        generated.


   (3)  The control information must be embodied in an appropriate MIME
        content types: application/key-request and
application/key-data.  These new content types are used to transmit
requests for key operations (storage, retrieval, certification,
revocation list retrieval, etc.) type.


   (4)  The control information body part and the responses to those requests.
These two content types are independent encrypted data body parts and are not required
to
        part must be encapsulated embodied in any other body part.  These changes represent a
departure in mechanism, not in effect, and multipart/encrypted content type.


   The first step is defined by MIME.  The latter three steps are detailed in Section 8.

In order
   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 make use encrypt
   the data itself.  The syntax of the PEM services, control information is that of a user
   set of RFC 822 headers, except that the folding of header values onto
   continuation lines is required to have at
least explicitly forbidden.  Each header and value
   pair generated by the encryption service must be output on exactly
   one public/private key pair.  Prior to this specification, line.

   First, the originator must retrieve the public key was required to of the recipient.
   The retrieval may be embodied in from a certificate, an object that





Crocker/Freed/Galvin/Murphy  Expires: May 1995                  [Page 2]

INTERNET DRAFT                PEM and MIME                 November 1994


binds local database or from a remote service.
   The acquisition of the recipient's public key with a distinguished name, a name form that
identified is outside the owner scope of
   the specification, although Section 5 defines one possible mechanism.

   With the public key. key, the originator encrypts the data encrypting key
   according to the Key-Info: header defined below.  The embodiment was issued complete set of
   headers generated by a
certification authority, a role that was expected to be trustworthy
insofar as it verified the identity encryption service is as follows.

   Version:
      indicates which version of the owner prior to issuing MOSS protocol the
certificate.  However, remaining headers
      represent and is defined in Section 2.1.2.1.

   DEK-Info:
      indicates the deployment of certificates algorithm and mode used to encrypt the creation
of data.




Crocker, et al              Standards Track                    [Page 12]

RFC 1848             MIME Object Security Services          October 1995


   Recipient-ID:
      indicates the hierarchy of certification authorities has been problematic.

Instead, this specification bases public key used to encrypt the PEM services on a public/private data encrypting key pair.  Each
      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 is required to belong to a user (where user is
not limited to being a human, e.g., it could be a process or a role)
which has a name.  There
   of Recipient-ID: and Key-Info: headers.  Headers are 3 name forms specified by this document.
For backward compatibility (and forward compatibility if always emitted
   in the order indicated.  The Recipient-ID: and Key-Info: headers are
   always emitted in pairs in the X.500
Directory becomes a ubiquitous service) order indicated, one pair for each
   recipient of the name forms 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
distinguished name.  In addition, email addresses
      Recipient-ID: and arbitrary strings
are allowed.

Since Key-Info header pair representing the originator
      of the encrypted data.  By doing so, if an originator sends a user may have more than one key pair,
      message to a name form recipient that is
insufficient for uniquely identifying a key pair.  A unique key selector
must returned undelivered, the
      originator will be assigned able to each key pair. 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 combination purpose of a name form 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
key selector uniquely identifies single argument
   indicating the algorithm and mode or a key comma separated pair of
   arguments where the second argument carries any cryptographic
   parameters required by the algorithm and each mode indicated in the first
   argument.

   The data encrypting key pair information header is
uniquely identified defined by a name form the grammar
   token <dekinfo> as follows.

      <dekinfo>  ::= "DEK-Info" ":" <dekalgid>
                     [ "," <dekparameters> ] CRLF

   The grammar tokens for the encryption algorithm and key selector combination.
Throughout this document, this combination is called an identifier.
There mode identifier
   (<dekalgid>) and the optional cryptographic parameters
   (<dekparameters>) are 5 identifiers specified defined by this document.

    NOTE: In 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 simplest case, data encrypting key selectors that will be assigned by
   used to decrypt the owners of data.  Presumably the recipient owns the private
   key pairs.  This works best when users
    generate their own and thus is less interested in identifying the owner of the key pairs for personal use, which they
    distribute to others asserting by declaration that
   and more interested in the public private key belongs to them.  When value itself.  Nonetheless,
   the assertion that recipient header may convey either or both pieces of information:

      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 corresponding to [4], the private key selector may to be assigned by that third party.


With a key pair for one's self and software that is both MIME and PEM
aware, an originating user may digitally sign arbitrary data and send it used to one or more recipients.  With
      decrypt the public keys of data encrypting key

      the recipients, a
user may encrypt name of the data so that only owner and which of the intended recipients can owner's private keys to use
      to decrypt and read it.  This specification separates these two services so
that an originator may apply either or both, in either order. the data encrypting key

   The name forms and identifiers are described in detail decision as to what information to place in the next
section.  Succeeding sections specify how PEM and MIME are used together
and other ancillary details.






Crocker/Freed/Galvin/Murphy  Expires: May 1995                  [Page 3]

INTERNET DRAFT                PEM and MIME                 November 1994


2.  Name Forms and Identifiers

Currently, [3] requires value rests
   entirely with the use of certificates 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 create and receive
PEM messages.  Within certificates, [4] requires managed by the use originator is outside the scope of
distinguished names as specified
   this specification.

   The recipient header is defined by the X.500 Series 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 Recommendations.
However, the Internet community has a great deal more experience with the use of electronic mail addresses as a name form and there key information header is a
desire to be able to use arbitrary strings to identify convey the owners of
public keys.  Hence, there encrypted
   data encrypting key.  Its value is a need to support name forms comma separated list of two
   arguments: the algorithm and mode identifier in which do not
conform to the expected usage of distinguished names.

When receiving PEM messages it data
   encrypting key is necessary to be able to uniquely
identify encrypted and the encrypted data encrypting key.

   The key pair used to create the message.  A certificate is one
mechanism that accomplishes this, since it information header is uniquely identified defined by the
combination of its issuer's distinguished name grammar token
   <asymkeyinfo> as follows.

      <asymkeyinfo>  ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF

   The grammar tokens for the encryption algorithm and its serial number.
In any case, an mode identifier is required that consists of both a name form
   (<ikalgid>) and key selector.

In addition, users may distribute their public keys via mechanisms
outside the scope of 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 specification, protocol,
      which includes support for example, in a file via
FTP.  Users receiving such keys will probably assign name forms to them
to be displayed when receiving messages created with them. symmetric signatures and key



Crocker, et al              Standards Track                    [Page 14]

RFC 1848             MIME Object Security Services          October 1995


      management.  As a result,
it is desirable to some of the grammar tokens defined
      there, for example, <ikalgid>, will include options that are not
      legal for this protocol.  These options must be able to explicitly specify ignored and have
      not been included in the public key 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
rather than an identifier of on the public key.

    NOTE:  A feature first body
   part of an enclosing multipart/encrypted.  Its content is comprised
   of being able to specify the public data encryption key
    explicitly is that it allows users used to exchange encrypted,
    anonymous mail.  In particular, receiving users will always know
    a message comes from encrypt the same originating user.


The principal objective of data in the various Originator second
   body part and Recipient fields
specified in [3] is other control information required to identify which public key has been decrypt the data,
   as defined by Section 2.2.1.  The label "application/moss-keys" must
   be used or is
required.  This document reduces as the set value of fields by specifying exactly
two: Originator-ID: for originators and Recipient-ID: for recipients.
This specification defines 5 identifiers with which the public key used
may be indicated in each protocol parameter of these fields.

In the next section enclosing
   multipart/encrypted; the 3 name forms are described in detail.  Following
that protocol parameter must be present.

   An application/moss-keys body part is constructed as follows:

      Content-Type: application/moss-keys

      <mosskeys>

   where the specification of the 5 identifiers.

2.1.  Name Forms

There are 3 name forms specified by this document: email addresses,
distinguished names, and arbitrary strings.





Crocker/Freed/Galvin/Murphy  Expires: May 1995 <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 4]

INTERNET DRAFT                PEM and 15]

RFC 1848             MIME                 November 1994


2.1.1.  Email Addresses Object Security Services          October 1995


   The email address (grammar token <emailstr>) used must be a valid RFC822
address, which <id> is defined in terms of the two grammar tokens <addr-spec>
and <route-addr>. Section 4.  The grammar for these two tokens is included in the
Appendix as a convenience; the definitive source for these tokens token <version> is
necessarily RFC822 [1].

    <emailstr>      ::= <addr-spec> / <route-addr>
                        ; an electronic mail address as
   defined by
                        ; these two in Section 2.1.2.1.  All other tokens from RFC822

For example, the strings "crocker@tis.com", "galvin@tis.com",
"murphy@tis.com", and "ned@innosoft.com" are all email addresses.

2.1.2.  Arbitrary Strings defined in Section
   2.2.1.3.

2.2.3.  Use of multipart/encrypted Content Type

   The arbitrary string (grammar token <string>) must have a length definition of at
least 1.  There are no other restrictions on the value chosen.

    <string>        ::= ; a non-null sequence of characters

For example, multipart/encrypted body part in [7] specifies
   three steps for creating the string

    Jim "the SAAG mailing list maintainer" Galvin

is an arbitrary string.

2.1.3.  Distinguished Names body part.


   (1)  The distinguished name (grammar token <dnamestr>) must body part to be constructed encrypted is created 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, a local
        convention, for example, specifies syntactic restrictions based on with a particular choice of text editor or a certification hierarchy mail user
        agent.


   (2)  The body part is prepared for certificates.

For the purposes of conveying a distinguished name from an originator encryption according to
a recipient, it the
        protocol parameter, in this case the body part must be ASN.1 encoded and then printably encoded in MIME
        canonical form.


   (3)  The prepared body part is encrypted according to the base64 encoding defined by MIME.

    <dnamestr>      ::= <encbin>
                        ; a printably encoded, ASN.1 encoded
                        ; distinguished name (as defined 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 'Name'
                        ; production specified in X.501)






Crocker/Freed/Galvin/Murphy  Expires: May 1995 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 5]

INTERNET DRAFT                PEM and 16]

RFC 1848             MIME                 November 1994


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 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
leading spaces present only to improve readability).  When encoded, it KEY-INFORMATION are
   descriptive of the content that would appear as follows (line breaks present only to improve
readability):

    MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3RlZCBJ
    bmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1UEAxMP
    SmFtZXMgTS4gR2Fsdmlu


2.2.  Identifiers

There are 5 types in a real body part.

3.  Removing MIME Object Security Services

   The verification of identifiers specified by this document: email
address identifiers, arbitrary string identifiers, distinguished name
identifiers, the public keys themselves, 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 issuer name serial number
pairs from a certificate.  All the control information.


   (3)  The public key of these have approximately the same
structure (except issuer name and serial number which has 'TYPE, STRING,
KEYSEL' for historical reasons):

    TYPE, KEYSEL, STRING originator.


   The TYPE field is a literal string, one for each signed data and control information of the possible
identifiers. enclosing
   multipart/signed are prepared according to the description below.
   The KEYSEL field digital signature is used to distinguish between verified by re-computing the multiple public keys
that may be associated with hash of the name form in
   data, decrypting the STRING field.  Its
value must be distinct from all other KEYSELs assigned by whomever
assigned this KEYSEL.  A suggested 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 to use a portion (low-order
16 or 32 bits) or all valid.

   The decryption of the actual public 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 used. of the recipient.


   The STRING field 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 name form recipient's private key
   and has a different syntax according used to decrypt the value of 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 TYPE field.
   MOSS digital signature service.  The identifier used in each definition of the originator
   multipart/signed body part in [7] specifies three steps for receiving
   it.


   (1)  The digitally signed body part and recipient fields is
described by the following grammar. control information body
        part are prepared for processing.


   (2)  The definition of prepared body parts are made available to the key selector
token is included here since it used by several digital
        signature verification process.


   (3)  The results of the identifiers





Crocker/Freed/Galvin/Murphy  Expires: May 1995                  [Page 6]

INTERNET DRAFT                PEM digital signature verification process are
        made available to the user and MIME                 November 1994


below.

    <id>            ::=   <id-email> / <id-string>    / <id-dname>
                        / <id-publickey> / <id-issuer>

    <keysel>        ::= <encbin>
                        ; a printably encoded non-null sequence of octets processing continues with the
        digitally signed body part, as returned by the digital signature
        verification process.


   Each of the identifier name forms these steps is described below.

2.2.1.  Email Address

3.1.1.  Preparation

   The email address identifier has digitally signed body part (the data) and the following syntax.

    <id-email>      ::= "EN"  "," <keysel> "," <emailstr> CRLF


The syntax of control information
   body part are separated from the token <emailstr> enclosing multipart/signed body
   part.




Crocker, et al              Standards Track                    [Page 18]

RFC 1848             MIME Object Security Services          October 1995


   The control information is defined in Section 2.1.1.

2.2.2.  Arbitrary String prepared by removing any content transfer
   encodings that may be present.

   The arbitrary string identifier has digitally signed body part is prepared by leaving the following syntax.

    <id-string>     ::= "STR" "," <keysel> "," <string> CRLF


The syntax of content
   transfer encodings intact and canonicalizing the token <string> is defined in line delimiters
   according to Step 2 of Section 2.1.2.

2.2.3.  Distinguished Name

The distinguished name identifier has 2.1.1.

3.1.2.  Verification

   First, the recipient must obtain the following syntax.

    <id-dname>      ::= "DN"  "," <keysel> "," <dnamestr> CRLF


The syntax public key of the token <dnamestr> is defined in Section 2.1.3.

2.2.4.  Public Key originator.
   The public key identifier has may be contained in the control information or it may
   be necessary for the recipient to retrieve the following syntax.










Crocker/Freed/Galvin/Murphy  Expires: May 1995                  [Page 7]

INTERNET DRAFT                PEM and MIME                 November 1994


    <id-publickey>  ::= "PK"  "," <publickey> [ "," <id-subset> ] CRLF

    <publickey>     ::= <encbin>
                        ; a printably encoded, ASN.1 encoded public key (as
                        ; defined by the 'SubjectPublicKeyInfo' production
                        ; specified based on
   information present in X.509)

    <id-subset>     ::= <id-email> / <id-string> / <id-dname> the control information.  The object subjectPublicKeyInfo is imported retrieval may be
   from the X.500 Directory a local database or from a remote service.  The acquisition of
   the certificate object.  It originator's public key is currently outside the scope of the
   specification, although Section 5 defines one possible mechanism.

   With the best choice for a
general purpose public key encoding.

In normal usage, key, the token <id-subset> recipient decrypts the hash value contained
   in the control information.  Then, a new hash value is expected computed over
   the body part purported to be absent.  When
present, it represents a mechanism by which 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 identifier (name form and
key selector) can be associated with indication as to whether a public key.  Recipients 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 a the public key identifier who is
   presumably the holder of the private key that created the digital
   signature.  The indication must take care include a testament as to verify the
   accuracy of the
purported association.  If not, it may be possible for owner identification.

   At issue is a malicious
originator to assert an identifier that accords recipient knowing who created the originator
unauthorized privileges.  See Section 5.2 digital signature.
   In order for more details.

2.2.5.  Issuer Name and Serial Number

The issuer the recipient to know with certainty who digitally
   signed the message, the binding between the owner's name and serial number identifier has the following syntax.

    <id-issuer>     ::= "IS"  "," <dnamestr>  "," <serial> CRLF

    <serial>        ::= 1*<hexchar>
                        ; hex dump of
   public key must have been verified by the serial number recipient prior to the
   verification of a certificate the digital signature.  The <id-issuer> identifier is included for backward compatibility (and
forward compatibility if X.500 Directory certificates become
ubiquitously available) with verification of the ID-ASymmetric fields defined
   binding may have been completed offline and stored in [3].
Its syntax was chosen such that a trusted,
   local database or, if the older fields owner's name and public key are easily converted embodied in
   a certificate, it may be possible to
this new form by prefixing the old value with "IS," and replacing the
field name with an appropriate new ID field name.

3.  Applying PEM complete it in realtime.  See
   Section 5 for more information.





Crocker, et al              Standards Track                    [Page 19]

RFC 1848             MIME Object Security Services to MIME Body Parts

The next          October 1995


3.2.  Encryption Service

   This section describes the processing steps necessary to prepare a
MIME body part for the application of PEM security services.  The
succeeding two sections describe the content of the multipart/signed and
multipart/encrypted body parts resulting from decrypt the application of PEM





Crocker/Freed/Galvin/Murphy  Expires: May 1995                  [Page 8]

INTERNET DRAFT                PEM and MIME                 November 1994


security services to MIME body parts.

3.1.  PEM Processing Steps
   MOSS encryption service.  The definition of the multipart/signed and multipart/encrypted
   body
parts part in [7] specifies three steps for creating both body parts. steps for receiving it.


   (1)  The encrypted body part to be protected is created according to a local
     convention.

(2)  The and the control information body part is
        are prepared for protection according to the protocol
     parameter.

(3) processing.


   (2)  The prepared body part is protected according to the protocol
     parameter.

This specification makes no changes parts are made available to step one in the sequence.  For
step two, there is no preparation necessary for decryption
        process.


   (3)  The results of the encryption service.
For decryption process are made available to the digital signature service,
        user and processing continues with the decrypted body part must be canonicalized part, as described below.  This specification makes no changes to step three
in the sequence.

Prior to
        returned by the application decryption process.


   Each of the digital signature service, the these steps is described below.

3.2.1.  Preparation

   The encrypted body part
must be in a canonical form.  Transforming (the data) and the control information body
   part to be signed
into a canonical form is a necessary and essential step in are separated from the digital
signature process. enclosing multipart/encrypted body part.
   The canonical form must satisfy body parts are prepared for the property decryption process by removing
   any content transfer encodings that it
is uniquely and unambiguously representable may be present.

3.2.2.  Decryption

   First, the recipient must locate the encrypted data encrypting key in both
   the originator and
recipient's local environment.  This control information.  Each Recipient-ID: header is required checked in
   order to ensure that
both see if it identifies the originator and recipient have or a public key of the
   recipient.

   If it does, the immediately following Key-Info: header will contain
   the same data encrypting key encrypted with which to
calculate the digital signature; public key of the originator needs to be able
   recipient.  The recipient must use the corresponding private key to
include
   decrypt the digital signature value when transferring data encrypting key.

   The data is decrypted with the data encrypting key.  The decrypted
   data will be a MIME object, a body part,
while the recipient needs 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 compare locate and decrypt a re-computed value with data encrypting key,
   from the received value.  Further, point of view of MOSS the canonical form decryption should satisfy the
property that it is representable on as many different host computers as
possible.  By satisfying this property, signed data may be forwarded by
recipients considered
   successful.  An indication of the owner of the private key used to additional recipients, who will also
   decrypt the data encrypting key must be able made available to verify the
original signature.  This service is called forwardable authentication.

The canonicalization transformation user.

   Ultimately, the success of the decryption is dependent on the ability
   of a two step process.  First, MIME agent to continue processing with the decrypted body part must be converted 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 uniquely and unambiguously
representable on as many different host computers expected to be trustworthy
   insofar as possible.  Second, the body part must certification authority would have its line delimiters converted procedures to a unique and
unambigous representation
   verify the identity of the owner prior to computing 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
prior
   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 verification of these headers serves a distinct purpose, for
   simplicity the digital signature.






Crocker/Freed/Galvin/Murphy  Expires: May 1995                  [Page 9]

INTERNET DRAFT                PEM single grammar token <id> represents the value that
   may be assigned to either header.

   One possible value for the Originator-ID: and MIME                 November 1994


The representation of all body parts in Recipient-ID: headers
   is the first step public key values themselves.  However, while it is specified to true that
   the public keys alone could be 7bit, as defined exchanged and used by [2].  Since users to
   communicate, the headers values are, in fact, large and cumbersome.  In
   addition, public keys would appear as a random sequence of body parts are already
required to characters
   and, as a result, would not be representable in 7bit, this step requires immediately consumable by human users.

      NOTE: It should be pointed out that if the
data a feature of being able to be signed
      specify the public key explicitly is not already 7bit then that it must be encoded with an
appropriate MIME content transfer encoding.  Note: since allows users to
      exchange encrypted, anonymous mail.  In particular, receiving
      users will always know a message comes from the MIME
standard explicitly disallows nested content transfer encodings, i.e., same originating
      user even if the content types multipart and message may not themselves be encoded,
body parts enclosed within, real identity of the originating user is unknown.

   Recognizing that the use of public keys is, in general, unsuitable
   for example, a multipart content type must
be encoded use by humans, MOSS allows other identifiers in Originator-ID:
   and Recipient-ID: headers.  These other identifiers are comprised of
   two parts: a 7bit representation.  Any valid name form and a key selector.




Crocker, et al              Standards Track                    [Page 21]

RFC 1848             MIME encoding may be
selected for encoding Object Security Services          October 1995


   The name form is chosen and asserted by the content of each of user who owns the non-7bit body parts.

As may be required
   public/private key pair.  Three name forms are specified by MIME, an appropriate Content-Transfer-Encoding:
header this
   document.  The use of a distinguished name is added and included retained for
   compatibility with PEM (and compatibility with the data to be signed.  Upon receipt, X.500 Directory
   should it become a MIME implementation would verify ubiquitous service).  However, the signature Internet
   community has a great deal of experience with the data prior use of electronic
   mail addresses as a name form.  Also, arbitrary strings are useful to
decoding
   identify the data owners of public keys when private name forms are used.
   Hence, email addresses and displaying it to the recipient.

Representing all complex content types arbitrary strings are included as 7bit transforms them into
text-based content types.  However, text-based content types present name
   forms to increase flexibility.

   Since a
unique problem.  In particular, user may have more than one public key and may wish to use
   the line delimiter used same name form for each public key, a text-based
content type name form is specific to insufficient
   for uniquely identifying 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>)". public key.  A unique "key selector" must
   be assigned to each public key.  The application combination of the digital signature service requires that the same
line delimiter be used by both the originator a name form 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 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
canonicalization transformation includes simplest case, key selectors will be assigned by the conversion
      owners of the local
line delimiter 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 two character sequence "<CR><LF>".

The conversion public key belongs to them.  When 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
      assertion that the line delimiter public key belongs to them is made by a local line delimiter, prior third
      party, for example when a certification authority issues a
      certificate to
    the message being delivered a user according to [4], the user.  Thus, a recipient has
    no way key selector may be
      assigned by that third party.

   The value of knowing if the conversion is present or not.  Thus, if
    the recipient applies the conversion key selector must be unique with respect to a content in the name
   form with which it is





Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 10]

INTERNET DRAFT                PEM and MIME                 November 1994


    already present, forms an identifier.  Although the resulting content same key
   selector value may have be used by more than one name form it must not be
   used for two line
    delimiters present, which would cause different keys with the verification of same name form.  When considered
   separately, neither a name form nor a key selector is sufficient for
   identifying the
    signature public key to fail.


    IMPLEMENTORS NOTE: Implementors should be aware that the
    conversion used.  Either could be used to
   determine a 7bit representation is a function set of public keys that is
    available in a minimally compliant MIME user agent.  Further,
    the line delimiter conversion required here is distinct from the
    same conversion included may be tried in that function.  Specifically, turn until the
    line delimiter conversion applied when a body part
   desired public key is converted
    to identified.

   With a 7bit representation public/private key pair for one's self and software that is performed prior
   MOSS aware, an originating user may digitally sign arbitrary data and
   send it to application of
    the transfer encoding.  The line delimiter conversion applied
    when a body part is signed is performed after one or more recipients.  With the body is
    converted to 7bit.


3.2.  Use public keys of multipart/signed Content Type

Using this content type requires the specification of
   recipients, a control
information content type, the label of which is used as user may encrypt the value for data so that only the required protocol parameter.  Section 3.4 defines intended
   recipients can decrypt and read it.  With the control
information content type of application/pem-signature.  The value of name forms assigned to
   the
required parameter "protocol" is "application/pem-signature" public keys, originators and recipients can easily recognize
   their peers in a communication.

   In the
value of the required parameter "micalg" is one of next section the valid choices
from [5], for example:

    Content-Type: multipart/signed; protocol="application/pem-signature";
      micalg="rsa-md5"; boundary="Signed Message"

    --Signed Message
    Content-Type: text/plain

    This is some example text.

    --Signed Message
    Content-Type: application/pem-signature

    SIGNATURE INFORMATION
    --Signed Message--


where SIGNATURE INFORMATION 3 name forms are described in detail.
   Following that is descriptive the specification of the content that would
appear in a real body part.






Crocker/Freed/Galvin/Murphy  Expires: May 1995 5 identifiers.



Crocker, et al              Standards Track                    [Page 11]

INTERNET DRAFT                PEM and 22]

RFC 1848             MIME                 November 1994


3.3.  Use of multipart/encrypted Content Type

Using Object Security Services          October 1995


4.1.  Name Forms

   There are 3 name forms specified by this content type requires the specification of document: email addresses,
   distinguished names, and arbitrary strings.

4.1.1.  Email Addresses

   The email address (grammar token <emailstr>) used must be a control
information content type, the label of valid
   RFC822 address, which is used as the value for
the required protocol parameter.  Section 3.5 defines the control
information content type defined in terms of application/pem-keys.  The value one of the
required parameter "protocol" is "application/pem-keys", two grammar
   tokens <addr-spec> or <route-addr>.  The grammar for example:

    Content-Type: multipart/encrypted; protocol="application/pem-keys";
      boundary="Encrypted Message"

    --Encrypted Message
    Content-Type: application/pem-keys

    KEY DATA

    --Encrypted Message
    Content-Type: application/octet-stream

    ENCRYPTED DATA WOULD BE HERE
    --Encrypted Message--


3.4.  application/pem-signature Content Type Definition

(1)  MIME type name: application

(2)  MIME subtype name: pem-signature

(3)  Required parameters: none

(4)  Optional parameters: none

(5)  Encoding considerations: quoted-printable is always sufficient

(6)  Security considerations: none

This content type these two tokens
   is used on included in the second body part of an enclosing
multipart/signed when Appendix as a convenience; the protocol used is PEM.  It definitive source
   for these tokens is comprised 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
digital signature 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 data, which 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 first body part guidelines of the
enclosing multipart/signed, and the information required to verify that
signature. X.500 Directory.  The label application/pem-signature actual
   syntax of the distinguished name is used as outside the value scope of
the protocol parameter this
   specification.  However, RFC1422, for example, specifies syntactic
   restrictions based on its choice of the enclosing multipart/signed.  It is an
error a certification hierarchy for
   certificates.

   For the protocol parameter to be missing purposes of conveying a distinguished name from the enclosing
multipart/signed body part or for its value an originator
   to a recipient, it must be different from





Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 12]

INTERNET DRAFT                PEM ASN.1 encoded and MIME                 November 1994


application/pem-signature when this body part is used.

Included in the signature verification information will be then printably encoded
   according to the Message
Integrity Check (MIC) algorithm used during 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 signature creation
process.  The MIC algorithm identified 'Name'
                          ; production specified in this body part must match the
MIC algorithm identified 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 micalg parameter public keys themselves

      issuer name serial number pairs from a certificate

   All of these have approximately the enclosing
multipart/signed.  If it does not, same structure (except issuer
   name and serial number which has 'TYPE, STRING, KEYSEL' for
   historical reasons):

      TYPE, KEYSEL, STRING

   The TYPE field is a user agent should identify literal string chosen from the
discrepancy to a user set "EN", "STR",
   "DN", "PK", and may choose to either halt or continue
processing, giving precedence to the algorithm identified in this body
part.

An application/pem-signature body part is constructed as follows:

    Content-Type: application/pem-signature

    <pemsig>


where "IS", one for each of the <pemsig> token is defined as follows.

    <pemsig>        ::= <version> ( 1*<origasymflds> )

    <version>       ::= "Version:" "5" CRLF

    <origasymflds>  ::= <origid> <micinfo>

    <origid>        ::= "Originator-ID:" <id> CRLF possible identifiers.

   The token <id> KEYSEL field is defined used to distinguish between the multiple public
   keys that may be associated with the name form in Section 2.2.

3.5.  application/pem-keys Content Type Definition

(1)  MIME type name: application

(2) 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 subtype name: pem-keys

(3)  Required parameters: none

(4)  Optional parameters: none

(5)  Encoding considerations: quoted-printable is always sufficient

(6) Object Security considerations: none






Crocker/Freed/Galvin/Murphy  Expires: May Services          October 1995                 [Page 13]

INTERNET DRAFT                PEM and MIME                 November 1994


This content type is used on


   with the first body part of an enclosing
multipart/encrypted.  It is comprised same name form.  An example would be to use a portion (low-
   order 16 or 32 bits) or all of the data encryption actual public key used used.

   The STRING field is the name form and has a different syntax
   according to
encrypt the data, located value of the TYPE field.

   The identifier used in the second body part each of the enclosing
multipart/encrypted, originator and recipient fields is
   described by the information required to perform the
decryption. following grammar.  The label application/pem-keys definition of the key
   selector token is included here since it used as the value by several of the
protocol parameter
   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 enclosing multipart/encrypted.  It identifier name forms is an error
for described below.

4.2.1.  Email Address

   The email address identifier has the protocol parameter to be missing in following syntax.

      <id-email>      ::= "EN"  "," <keysel> "," <emailstr> CRLF

   The syntax of the enclosing
multipart/encrypted body part or for its value to be different from
application/pem-keys when this body part token <emailstr> is used.

An application/pem-keys body part defined in Section 4.1.1.

   For example:

      EN,1,galvin@tis.com

   is constructed as follows:

    Content-Type: application/pem-keys

    <pemkeys>


where 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 <pemkeys> token <string> is defined as follows.

    <pemkeys>       ::= <version> <dekinfo> 1*<recipasymflds>

    <version>       ::= "Version:" "5" CRLF

    <recipasymflds> ::= <recipid> <asymkeyinfo>

    <recipid> 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>      ::= "Recipient-ID:" <id> "DN"  "," <keysel> "," <dnamestr> CRLF

    <asymkeyinfo>

   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>  ::= "Key-Info" ":" <ikalgid> "PK"  "," <asymencdek> <publickey> [ "," <id-subset> ] CRLF


The token <id> is

      <publickey>     ::= <encbin>
                          ; a printably encoded, ASN.1 encoded public
                          ; key (as defined by the
                          ; 'SubjectPublicKeyInfo' production specified
                          ; in Section 2.2.

4.  Removing PEM Security Services X.509 [9])

      <id-subset>     ::= <id-email> / <id-string> / <id-dname>

   The production SubjectPublicKeyInfo is imported from PEM Body Parts

This section describes the processing steps necessary 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 verify or
decrypt improve readability):

      PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6BekJmG
      4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn
      0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB

   is a public key identifier without the PEM security services that have been applied optional <id-subset>.

   In normal usage, the token <id-subset> is expected to MIME body
parts.  Outer layers of PEM security services must be processed prior to
processing inner layers present.  It
   represents a mechanism by which an identifier (name form and key
   selector) can be associated with a public key.  Recipients of PEM security services.  Processing includes a
user choosing
   public key identifier must take care to display a content without removing verify the PEM security
services.

The definition accuracy of the multipart/signed and multipart/encrypted body
parts in [7] specifies three steps
   purported association.  If they do not, it may be possible for receiving both body parts.







Crocker/Freed/Galvin/Murphy  Expires: May 1995 a
   malicious originator to assert an identifier that accords the



Crocker, et al              Standards Track                    [Page 14]

INTERNET DRAFT                PEM and 26]

RFC 1848             MIME                 November 1994


(1) 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 protected body part and the control information body part are
     prepared <id-issuer> identifier is included for processing.

(2)  The prepared body parts are made available to compatibility with the protection
     removal process.

(3)  The results of
   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 protection removal process older fields are made available easily converted
   to this new form by prefixing the user and processing continues old value with "IS" (and replacing
   the unprotected body part,
     as returned by the protection removal process. field name of [3] with an appropriate new ID field name).  For step one, the preparation for digitally signed and encrypted body
parts is different, as described below.  No changes are required
   example, (line breaks present only to
steps two and three in the sequence.

For multipart/signed body parts, the control information is prepared by
removing any content transfer encodings that may be present.  The
digitally signed body part improve readability):

      IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3
      RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02

   is prepared by leaving the content transfer
encodings intact an issuer name and converting the line delimiters serial number identifier according to Step 2
of Section 3.1.

Multipart/encrypted body parts are prepared by removing the content
transfer encodings, if present, from both the control information MOSS,
   while

      MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3
      RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02

   is an issuer name and
the encrypted body part. serial number identifier according to PEM.

5.  Key Management Content Types

   This document defines two key management content types, 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 contents of
which comprise a replacement mechanism for those defined in [6].  The
first content type is application/pemkey-request, which replaces the
certification types
   may also be used to convey certificate and CRL-retrieval request messages. certificate revocation
   list material.

   The second content
type is application/pemkey-data, which replaces the certification reply
message, the crl-storage request message, and the crl-retrieval reply
message.  There functions defined here are no requirements for based on the exchange of body parts.
   In particular, a user would send a crl-storage reply message and
none are specified in this document.  This document includes containing at least one
   application/mosskey-request content, as defined below.  In response,
   a
specification 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 public key and certificate user to send several request message, which
were previously undefined. body parts
   and to receive several data (response) body parts in one message.

5.1.  application/pemkey-request  application/mosskey-request Content Type Definition

   (1)  MIME type name: application

   (2)  MIME subtype name: pemkey-request mosskey-request

   (3)  Required parameters: none






Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 15]

INTERNET DRAFT                PEM and MIME                 November 1994

   (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



This

   A user would use this content type is used to provide for some of the request messages
described in [6]. specify needed cryptographic
   key information.  The information in 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.  As such, the application/pemkey-
request content type is an independent body part.

The certification request, certificate-retrieval request and crl-
retrieval request are provided for directly.





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 2.2.

The crl-storage request is provided for by the application/pemkey-data
content type described in the Section 5.2.

In each case, the 4.

   One possible response is transmitted in to receiving an application/pemkey-data
content type. 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/pemkey-data application/mosskey-data body parts are to be returned in the
   reply message, one for each.






Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 16]

INTERNET DRAFT                PEM and MIME                 November 1994

5.2.  application/pemkey-data  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, thus setting up the destination such that when the data is
used sensitive information may be intercepted and disclosed
inappropriately. identifier.

   It is incumbent upon a recipient to verify the authenticity and
   accuracy of the data received in this way prior to its use.  The  This
   problem is 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 application/key-data
   source of the application/mosskey-data body part could be digitally signed by the source. 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
key data received contents of the
   application/mosskey-data from the source can could be believed. 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/pemkey-data application/mosskey-data body part is a
      similar mechanism.

   (1)  MIME type name: application

   (2)  MIME subtype name: pemkey-data 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.








Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 17]

INTERNET DRAFT                PEM and MIME                 November 1994


    <keydata>

      <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/pemkey-data
   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 2.2.4. 4.2.4.

   The <certchain> production contains one certificate chain.  A
   certificate chain starts with a 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.






Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 18]

INTERNET DRAFT                PEM and MIME                 November 1994

6.  Examples

Given

   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 email message prepared for submission: is used as the
   message to be protected.

      To: Ned Freed <ned@innosoft.com>
      Subject: Hi Ned!

      How do you like the new MIME/PEM? 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
   this, where lines with an ampersand '&' are digitally signed (note
   the use of the public key identifier with the included email name
identifier):
   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/pem-signature";
          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 MIME/PEM? MOSS?
      &
      & Jim

        --Signed Boundary
        Content-Type: application/pem-signature application/moss-signature
        Content-ID: <21436.785186814.1@tis.com>
        Content-Transfer-Encoding: quoted-printable

        Version: 5
      * Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6B=
    ekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn0Lw8g=
    G67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,galvin@tis.com PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4f=
      * qQ61aoC1fO6BekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8=
      * KRGJ9wh1HU4TrghGdhn0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,=
      * 2,galvin@tis.com
        MIC-Info: RSA-MD5,RSA,PnEvyFV3sSyTSiGh/HFgWUIFa22jbHoTrFIMVERfMZXUKzFsHbmK=
    tIowJlJR56OoImo+t7WjRfzpMH7MOKgPgzRnTwk0T5dOcP/lfbsOVJjleV7vTe9yoNp2P8mi/h=
    s7 RSA-MD5,RSA,PnEvyFV3sSyTSiGh/HFgWUIFa22jbHoTrFIMVERf=
        MZXUKzFsHbmKtIowJlJR56OoImo+t7WjRfzpMH7MOKgPgzRnTwk0T5dOcP/lfb=
        sOVJjleV7vTe9yoNp2P8mi/hs7

        --Signed Boundary--






Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 19]

INTERNET DRAFT                PEM

6.3.  Sign Headers and MIME                 November 1994 Text of Original Message

   If, instead, we choose to protect the headers with the text, text of the
   original message, it will look like this: 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/pem-signature";
          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 MIME/PEM? MOSS?
      &
      & Jim

        --Signed Boundary
        Content-Type: application/pem-signature application/moss-signature
        Content-ID: <21468.785187044.1@tis.com>
        Content-Transfer-Encoding: quoted-printable

        Version: 5
        Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6B=
    ekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn0Lw8g=
    G67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,galvin@tis.com PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4f=
        qQ61aoC1fO6BekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8=
        KRGJ9wh1HU4TrghGdhn0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,=
        2,galvin@tis.com
        MIC-Info: RSA-MD5,RSA,ctbDBgkYtFW1sisb5w4/Y/p94LftgQ0IrEn3d6WTwjfxFBvAceVW=
    fawsZPLijVKZUYtbIqJmjKtzTJlagBawfA/KhUsvTZdR6Dj+4Gd8dBBwMKvqMKTHAUxGXYxwNd=
    bK 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 asterick (*):











Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 20]

INTERNET DRAFT                PEM and MIME                 November 1994 asterisk '*':

        To: Jim Galvin <galvin@tis.com>
        Subject: an encrypted message

      * How do you like the new MIME/PEM? 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):
   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/pem-keys";
          protocol="application/moss-keys";
          boundary="Encrypted Boundary"

        --Encrypted Boundary
        Content-Type: application/pem-keys 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/WZ=
    q05lN99RDUQhdNxXI64ePAbFWQ6RGoiCrRs+Dc95oQh7EFEPoT9P6jyzcV1NzZVwfp+u RSA,ISbC3IR01BrYq2rp493X+Dt7WrVq3V3/U/YXbxOTY5cmiy1/=
        7NvSqqXSK/WZq05lN99RDUQhdNxXI64ePAbFWQ6RGoiCrRs+Dc95oQh7EFEPoT=
        9P6jyzcV1NzZVwfp+u

        --Encrypted Boundary
        Content-Type: application/octet-stream
        Content-Transfer-Encoding: base64

    AfR1WSeyLhy5AtcX0ktUVlbFC1vvcoCjYWy/yYjVj48eqzUVvGTGMsV6MdlynUd4jcJgRnQIQvIx
    m2VRgH8W8MkAlul+RWGu7jnxjp0sNsU562+RZr0f4F3K3n4wonUUP265UvvMj23RSTguZ/nl/Oxn
    FM6SzDgV39V/i/RofqI=

        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 follows, where lines with an asterick asterisk '*' are
   digitally signed and lines with an ampersand '&' are encrypted):








Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 21]

INTERNET DRAFT                PEM and MIME                 November 1994 encrypted:

          Content-Type: multipart/encrypted;
            protocol="application/moss-keys";
            boundary="Encrypted Boundary"

          --Encrypted Boundary
          Content-Type: application/pem-keys 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 MIME/PEM? MOSS?
      & *
      & * Jim
      &
      &   --Signed Boundary
      &   Content-Type: application/pem-signature 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/Freed/Galvin/Murphy  Expires: May 1995










Crocker, et al              Standards Track                    [Page 22]

INTERNET DRAFT                PEM and 35]

RFC 1848             MIME                 November 1994 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/pem-keys";
        protocol="application/moss-keys";
        boundary="Encrypted Boundary"

      --Encrypted Boundary
      Content-Type: application/pem-keys 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+nOuOwP0tsym6CQozD9IwVIJzY8+vIfbh5B=
    pR0kS6prq3EGFBFR8gRMUvbgHtEKPD/4ICQ7b6ssZ7FmKhl/cJC5rVjpb4EOUlwOXwRZ RSA,AZTtlEc6xm0vjkvtVUITUh7sz+nOuOwP0tsym6CQozD9IwVIJz=
      Y8+vIfbh5BpR0kS6prq3EGFBFR8gRMUvbgHtEKPD/4ICQ7b6ssZ7FmKhl/cJC5rV=
      jpb4EOUlwOXwRZ

      --Encrypted Boundary
      Content-Type: application/octet-stream
      Content-Transfer-Encoding: base64

    ZvWvtosDzRBXJzkDFFRb9Qjrgm2nDWg3zotJ3ZpExpWUG/aRJ7Vwd+PWkSfrDPJ52V/wkxwMrum6
    xJHZonrtyd0AvaztvriMm2zXTefzwpGG1i5zK47PBqreLA3HDTK2U6B13vzpE8wMSVefzaCTSpXR
    SCh08ceVEZrIYS53/CKZV2/Sga71pGNlux8MsJpYLwdj5Q3NKocg1LMngMo8yrMAe+avMjfOnhui
    49Xon1Gft+N5XDH/+wI9qxI9fkQvNZVDlWIhCYEkxd5ke549tLkJjEqHQbgJW5C+K/uxdiD2dBt+
    nRCXcuO0Px3yKRyYg/9BgTf36padSHuv48xBg5YaqaEWpEzLI0Qd31vAyP23rqiPhfBn6sjhQ2Kr
    WhiF2l3TV8kQsIGHHZUkaUbqkXJe6PEdWWhwsqCFPDdkpjzQRrTuJH6xleNUFg+CG1V+tL4IgMjQ
    qm3KVojRXx8bG2auVN89NfwFswmoq4fXTrh3xyVS1VgxjKkcYI8SVVmkYjCxVviJP3zO2UzBvCoM
    fADtBVBz1njYETtVGDO97uT39MqL85uEgiF4E5TkOj/m04+88G0/vvN/RISKJiFQJ3FyVIB/ShX9
    Dixl8WCx3rxwN5g2QFLiyQVulzuNhimSD4ZxEo7smcTsAXUjwSLRtdjmTTutw2GmFESUaIrY81Nc
    pQJRPNAvF0IkN6ddwL4qvzUS99vjQp15g9FUv82lHtHwhM18a9GokVG8xYOjBBsn9anp9abh4Tp/
    c/vpbunQUqnpV29rF4wj+8OwUOMi9ymGabBXAjw7DhNH2RdRVr1upQO896OX81VWB0LsA0cp+ymx
    hTrEI+wCHcrsNMoRK/7zAeuAi0f1t9bN594EFlLoIrBnKEa1/OUAhMT7kG1fNkSRnc8BZswIoPyR
    etsTurQfD40nsVHvNwE9Jz7wbBo00gd6blPADOUYFxfW5zu6ubygBqJiKPM4II2fCdNj7CptfQco
    RTeguKMVPLVmFg/EINuWBFm10GqlYT7p4zhfzysV/3r5LVZ1E8armTCRJ2GoYG5h+SKcytaQ0IT8
    S2nLPCZl1hzdajsrqHFe8omQ

      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 PEM MOSS services as defined here will protect
   arbitrary body parts, for example, the following audio body part:








Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 23]

INTERNET DRAFT                PEM and MIME                 November 1994

      Content-Type: audio/basic

      AUDIO DATA HERE


when

6.6.1.  Sign Audio Content

   When signed an audio content would appear as follows: follows, where lines
   with an ampersand '&' are digitally signed:

        Content-Type: multipart/signed; protocol="application/pem-signature";
          protocol="application/moss-signature";
          micalg="rsa-md5"; boundary="Signed Boundary"

        --Signed Boundary
      & Content-Type: audio/basic
      & Content-Transfer-Encoding: base64

    base64(AUDIO DATA HERE)
      &
      & base64(AUDIO-DATA-HERE)

        --Signed Boundary
        Content-Type: application/pem-signature

    SIGNATURE INFORMATION HERE application/moss-signature

        SIGNATURE-INFORMATION-HERE

        --Signed Boundary--

   where AUDIO-DATA-HERE and when 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: 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/pem-keys";
          protocol="application/moss-keys";
          boundary="Encrypted Boundary"

        --Encrypted Boundary
        Content-Type: application/pem-keys

    KEY INFORMATION HERE application/moss-keys

        KEY-INFORMATION-HERE

        --Encrypted Boundary
        Content-Type: application/octet-stream
        Content-Transfer-Encoding: base64

    base64(encrypted(AUDIO DATA HERE))

      & 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 the pre-submission and post-delivery processing steps to
combine PEM and MIME capabilities and the framework defined by [7] exhibits several
   properties:





Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 24]

INTERNET DRAFT                PEM and MIME                 November 1994


   (1)  It allows privacy-enhancement of an arbitrary content, content types to be protected, not just the
        body of an RFC822 message.


   (2)  For  It allows a multipart or message content, it allows the user to specify
     different privacy enhancements to contain several body parts which may or
        may not be applied to different
     components of the structure of the content. protected.


   (3)  It provides for messages containing several privacy enhanced
     contents, thereby removing allows the requirement for PEM software to be
     able to generate or interpret components of a single multipart or message content which intermixes
     both unenhanced and enhanced components. to be
        protected with different services.


   The use of a MIME-capable user agent makes complex nesting of enhanced
   protected message body parts much easier.  For example, the user can
   separately sign and encrypt a message.  This motivates a 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, for
example, the way that the RSA algorithm does; 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.  Summary  Comparison of Changes 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 Specification

This document updates currently only supports text-based electronic mail messages
        and the message encryption and signature procedures
defined text is required to be represented by [3] and replaces the key certification and related services
defined by [6].  The changes are enumerated below.

(1) 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
     recursively in any order according to the needs of the
        requesting application.

(2)  PEM implementations are currently restricted to processing only
     text-based electronic mail messages.  In fact, the message text is
     required to be represented by the ASCII character set with
     "<CR><LF>" line delimiters.  This restriction no longer applies.






Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 25]

INTERNET DRAFT                PEM and MIME                 November 1994


(3)


   (5)  MIME includes transfer encoding operations to ensure the
        unmodified transfer of body parts, which obviates parts.  Therefore, unlike PEM, MOSS
        does not need to include these services in PEM.

(4) 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 included includes a decimal number that was 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.

(5)


   (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.

(6)


   (8)  The PEM specifications include a document that defines new types
        of PEM messages, specified by unique values used in the Proc-Type: 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.

(7) 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/pemkey-data application/mosskey-data and
     application/pemkey-request
        application/mosskey-request content types and are no longer
        allowed in the header portion of a PEM signed or encrypted
        message.

(8)  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].

(9)


   (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.

(10)


   (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: MIC-
        Info: field is associated with the encryption security service
        under asymmetric key managment, management, there is no requirement in that case to





Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 26]

INTERNET DRAFT                PEM and MIME                 November 1994


     include an Originator-ID field.

These changes represent a departure in mechanism, not in effect, from
those specified in [3] and [6].  The following technical changes no requirement in that
        case to [3]
and [4] are also specified by this document.

(1) include an Originator-ID field.


   (13) The grammar protocol specified here explicitly excludes symmetric key



Crocker, et al              Standards Track                    [Page 40]

RFC 1848             MIME Object Security Services          October 1995


        management.  Currently, there are no generally available
     implementations of symmetric key management nor are there any known
     plans for implementing it.  As a result, the IETF standards process
     will require this feature to be dropped when the documents are
     promoted to draft standard status from proposed standard status.

(2)


   (14) This document requires all data that is to be digitally signed
        to be represented in 7bit form.

(3)


9.  Security Considerations

   This entire document broadens is about security.

10.  Acknowledgements

   David H. Crocker suggested the allowable name forms that users may use
     to identify their public keys.  Users may use arbitrary strings 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
     email addresses as their name.  Further, users may distribute their
     public key directly 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 lieu of using certificates.  In support of
     this change the Originator-ID-ASymmetric:
       collaboration, and Recipient-ID-
     ASymmetric: fields are deprecated technically aligned, with ISO 9594-2.

   [9] The Directory -- Authentication Framework.  X.509, 1988.
       Developed in favor of Originator-ID: collaboration, and
     Recipient-ID: fields, respectively.

9. 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/pem-signature application/moss-signature body part is as follows:

    <pemsig>

      <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/pem-keys application/moss-keys body part is as follows:









Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 27]

INTERNET DRAFT                PEM and MIME                 November 1994


    <pemkeys>

      <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>        ::= <encbin> 1*<hexchar>
                          ; hex dump of a printably encoded 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 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
                          ; subjectPublicKeyInfo in X.509 [9])

      <serial>        ::= 1*<hexchar>
                          ; hex dump of the serial number of a certificate






Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 28]

INTERNET DRAFT                PEM and MIME                 November 1994 serial number


   The content of an application/pemkey-request application/mosskey-request body part is as
   follows:

      <request>       ::= <version>
                          ( <subject> / <issuer> / <certification> )

    <subject>       ::= "Subject:" <id> CRLF

    <issuer>        ::= "Issuer:" <id> CRLF

    <certification> ::= "Certification:" <encbin> CRLF


The content of an application/pemkey-data body part is as follows:

    <keydata>       ::= <version>
                        ( <publickeydata> / <certchain> / <crlchain> )

    <publickeydata> ::= "Key:" "PK" "," <publickey> "," <id-subset> CRLF

    <certchain>     ::= <cert> *( [ <crl> ] <cert> )

    <crlchain>      ::= 1*( <crl> [ <cert> ] )

    <cert>          ::= "Certificate:" <encbin> CRLF

    <crl>           ::= "CRL:" <encbin> CRLF


10.  Security Considerations

This entire document is about security.

11.  Acknowledgements

David H. Crocker suggested the use of a multipart structure for MIME-PEM
interaction.

12.  References

[1]  David H. Crocker.  Standard for the Format of ARPA Internet Text
     Messages.  RFC 822, University of Delaware, August 1982.

[2]  Nathaniel Borenstein and Ned Freed. MIME (Multipurpose Internet
     Mail Extension) Part One: Mechanisms for Specifying and Describing
     the Format of Internet Message Bodies.  RFC 1521, Bellcore and





Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 29]

INTERNET DRAFT                PEM and MIME                 November 1994


     Innosoft, September 1993.  Obsoletes RFC 1341.

[3]  John Linn.  Privacy Enhancement for Internet Electronic Mail: Part
     I: Message Encryption and Authentication Procedures.  RFC 1421,
     February 1993.  Obsoletes RFC 1113.

[4]  Steve Kent.  Privacy Enhancement for Internet Electronic Mail: Part
     II: Certificate-Based Key Management.  RFC 1422, BBN
     Communications, February 1993.

[5]  David M. Balenson.  Privacy Enhancement for Internet Electronic
     Mail: Part III: Algorithms, Modes, and Identifiers.  RFC 1423,
     Trusted Information Systems, February 1993.

[6]  Burton S. Kaliski.  Privacy Enhancement for Internet Electronic
     Mail: Part IV: Key Certification and Related Services.  RFC 1424,
     RSA Laboratories, February 1993.

[7]  James Galvin, Sandy Murphy, Steve

      <version>       ::= "Version:" "5" CRLF




Crocker, and Ned Freed.  Security
     Multiparts for MIME: Multipart/Signed and Multipart/Encrypted.
     RFC XXXX, Trusted Information Systems and Innosoft, XXXX 1994.

13.  Authors' Addresses

    Steve Crocker
    email:  crocker@tis.com

    James M. Galvin
    email:  galvin@tis.com

    Sandra Murphy
    email:  murphy@tis.com

    Trusted Information Systems
    3060 Washington Road
    Glenwood, MD  21738
    Tel:    +1 301 854 6889
    FAX:    +1 301 854 5363












Crocker/Freed/Galvin/Murphy  Expires: May 1995 et al              Standards Track                    [Page 30]

INTERNET DRAFT                PEM and 45]

RFC 1848             MIME                 November 1994


    Ned Freed
    Innosoft International, Inc.
    1050 East Garvey Avenue South
    West Covina, CA 91790
    Tel:    +1 818 919 3600
    FAX:    +1 818 919 3614
    email:  ned@innosoft.com











































Crocker/Freed/Galvin/Murphy  Expires: May 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 31]

INTERNET DRAFT                PEM and 46]

RFC 1848             MIME                 November 1994


14.  Appendix: Object Security Services          October 1995


Appendix B: Imported Grammar

The following productions are taken from [3].  The grammar presented

   Options normally present in
[3] remains the authoritative source for these productions; they are
repeated grammar reprinted here which are
   illegal in MOSS are excluded in this reprinting, for the convenience
   of the reader.

    <dekinfo>    ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF

    <micinfo>    ::= "MIC-Info" ":" <micalgid> "," <ikalgid> ","
                     <asymsignmic> CRLF

    <encbin>     ::= 1*<encbingrp>
    <encbingrp>  ::= 4*4<encbinchar>
    <encbinchar> ::= ALPHA / DIGIT / "+" / "/" / "="

   The following productions are taken from [5].  The grammar presented
   in [5] remains the authoritative source for these productions; they
   are repeated here for the convenience of the reader.

      <dekalgid>         ::= "DES-CBC"
      <ikalgid>          ::= "DES-EDE" / "DES-ECB" / "RSA"
      <micalgid>         ::= "RSA-MD2" / "RSA-MD5"

      <dekparameters>    ::= <DESCBCparameters>
      <DESCBCparameters> ::= <IV>
      <IV>               ::= <hexchar16>
      <hexchar16>        ::= 16*16<hexchar>

      <asymsignmic>      ::= <RSAsignmic>
      <RSAsignmic>       ::= <encbin>

      <asymencdek>       ::= <RSAencdek>
      <RSAencdek>        ::= <encbin>

    <hexchar16>        ::= 16*16<hexchar>
    <hexchar>          ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
                                                        ; no lower case

   The following productions are taken from [1].  The grammar presented
   in [1] remains the authorative authoritative source for these productions; they
   are repeated here for the convenience of the reader.








Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 32]

INTERNET DRAFT                PEM and MIME                 November 1994

      <route-addr>    ::= "<" [ <route> ] <addr-spec> ">"

      <route>         ::= <local-part>  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

    <route-addr>    ::= "<" [ <route> ] <addr-spec> ">"

    <route>         ::=  1# ( "@" <domain>

      <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>
                                                   ; path-relative => 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-
                          /  "," / ";" / ":" / " "\" / <">
                          /  "." / "[" / "]"
                                                   ; Must be in quoted-
                                                   ; string, to use
                                                   ;  within a word.









Crocker/Freed/Galvin/Murphy  Expires: May 1995                 [Page 33]

INTERNET DRAFT                PEM and MIME                 November 1994


Table of Contents


  Status of this Memo .............................................    1
  Abstract ........................................................    1
1  Introduction ...................................................    2
2  Name Forms and Identifiers .....................................    4
2.1  Name Forms ...................................................    4
2.1.1  Email Addresses ............................................    5
2.1.2  Arbitrary Strings ..........................................    5
2.1.3  Distinguished Names ........................................    5
2.2  Identifiers ..................................................    6
2.2.1  Email Address ..............................................    7
2.2.2  Arbitrary String ...........................................    7
2.2.3  Distinguished Name .........................................    7
2.2.4  Public Key .................................................    7
2.2.5  Issuer Name and Serial Number ..............................    8
3  Applying PEM Security Services to MIME Body Parts ..............    8
3.1  PEM Processing Steps .........................................    9
3.2  Use of multipart/signed Content Type .........................   11
3.3  Use of multipart/encrypted Content Type ......................   12
3.4  application/pem-signature Content Type Definition ............   12
3.5  application/pem-keys Content Type Definition .................   13
4  Removing PEM Security Services from PEM Body Parts .............   14
5  Key Management Content Types ...................................   15
5.1  application/pemkey-request Content Type Definition ...........   15
5.2  application/pemkey-data Content Type Definition ..............   17
6  Examples .......................................................   19
7  Observations ...................................................   24
8  Summary of Changes to PEM Specification ........................   25
9  Collected Grammar ..............................................   27
10  Security Considerations .......................................   29
11  Acknowledgements ..............................................   29
12  References ....................................................   29
13  Authors' Addresses ............................................   30
14  Appendix: Imported Grammar ....................................   32














Crocker/Freed/Galvin/Murphy  Expires: May 1995

      <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 34] 48]

----