[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Internet Draft                                                  C. Adams
draft-ietf-cat-p7im-00.txt                                        NORTEL
Expires: November 30, 1996                                 May  30, 1996

                    PKCS #7-Based IDUP Mechanism (p7im)

STATUS OF THIS MEMO

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (West Coast), or munnari.oz.au (Pacific Rim).

   Comments on this document should be sent to "cat-ietf@mit.edu", the
   IETF Common Authentication Technology WG discussion list.

ABSTRACT

   The Independent Data Unit Protection Generic Security Service
   Application Program Interface (IDUP-GSS-API) extends the GSS-API
   [RFC-1508] for applications requiring protection of a generic data
   unit (such as a file or message) in a way which is independent of the
   protection of any other data unit and independent of any concurrent
   contact with designated "receivers" of the data unit.  Thus, it is
   suitable for applications such as secure electronic mail where data
   needs to be protected without any on-line connection with the
   intended recipient(s) of that data.  Subsequent to being protected,
   the independent data unit can be transferred to the recipient(s) - or
   to an archive - perhaps to be processed only days or years later.

   This document is a companion document to IDUP-GSS-API [IDUP] and
   IDUP: C-bindings [IDUP-C].  It provides a PKCS #7-based mechanism
   for IDUP (analogous to [Kerb5] or [SPKM] which provide underlying
   mechanisms for [GSS]).  This mechanism specifies the procedures
   for creating and processing security formats according to that
   defined by the Public-Key Cryptography Standards set of documents
   (specifically Part 7 of the set [PKCS7], which specifies the
   "Cryptographic Message Syntax Standard").  Calling applications can
   use this IDUP mechanism to assist them in creating true S/MIME
   [S/MIME] objects.  More precisely, a calling application is assumed
   by this mechanism to be MIME-aware and thus capable of performing all
   necessary canonicalization and (base64 or quoted-printable) encoding
   on the data.  The application thus uses the mechanism specified in
   this document exclusively for the security aspects of S/MIME.


Adams                Document Expiration:  30 Nov. 1996                1

1. INTRODUCTION

   The Independent Data Unit Protection Generic Security Service
   Application Program Interface (IDUP-GSS-API) [IDUP] provides security
   services to calling applications in a local environment.  This
   PKCS #7-Based IDUP Mechanism (p7im) allows an application to
   "protect" an independent data unit (IDU) for future use and to
   "unprotect" a protected IDU, applying security services such as
   confidentiality, integrity and data origin authentication on a
   per-data-unit basis.

   There are four stages to using the IDUP-GSS-API:

   (a) The application acquires a set of credentials with which it may
       bind its identity to a data unit.  The application's credentials
       vouch for its global identity, which may or may not be related to
       the local username under which it is running.

   (b) The application establishes a security environment using its
       credentials.  The security environment contains whatever
       information is necessary in order to provide per-IDU security
       services.

   (c) Per-IDU calls are invoked to provide one of the following for
       PKCS #7-based IDU protection:
         - data origin authentication with data integrity (SignedData);
         - data confidentiality (EnvelopedData);
         - both of the above (SignedAndEnvelopedData).
       The application wishing to "protect" an IDU will call the
       protection set of IDUP-GSS-API routines, specifying the
       appropriate security environment.  The recipient (wishing to
       "unprotect" the data) will pass the protected IDU (P-IDU) to
       the unprotection set of routines to remove the protection and/or
       to validate the data.

   (d) At the completion of a security environment (which may extend
       across several protection and unprotection operations), the
       application calls an IDUP-GSS-API routine to abolish the security
       environment.


2. INDEPENDENT DATA UNIT PROTECTION MECHANISM

2.1. Protection Token

   A P-IDU is a caller-opaque data structure that p7im uses to store
   protection information regarding an IDU.  It is an OCTET STRING
   generated during the protection set of calls for use by p7im or by
   another mechanism during the unprotection set of calls.  If
   encapsulation is requested by the calling application, the P-IDU
   consists entirely of the contents of the pidu_buffer, output_buffer,
   and final_pidu_buffer parameters used in the IDUP protection set of
   calls.  Otherwise, the P-IDU consists of the contents of the
   midu_buffer, output_buffer, and final_midu_buffer parameters, along
   with the unencapsulated_token parameter.

Adams                Document Expiration:  30 Nov. 1996                2

2.2. Security Services

   p7im provides the security services given in Section 1(c) above.
   The security services "proof of origin" and "service solicitation"
   (such as a request for "proof of delivery"), as defined in [IDUP],
   are not included in this PKCS #7-based IDUP mechanism.  Receipt
   generation and processing are beyond the scope of [S/MIME] and
   other types of non-repudiable evidence generation and processing are
   not addressed in this version of p7im but may be included in future
   versions of this specification.


2.3. IDUP Parameter Bundle Uses and Defaults

   The following parameter bundle uses and defaults are specified.


   Mech_Specific_Info
      - NOT USED (the only acceptable input, therefore, is NULL)

   Idu_Sensitivity
      - NOT USED (the only acceptable input, therefore, is NULL)

   Service_Creation_Info
      - NOT USED (the only acceptable input, therefore, is NULL)

   Service_Verification_Info
      - NOT USED (the only acceptable input, therefore, is NULL)

   Quality
      - the qop_algs parameter is supported.  For p7im implementation
        and interoperability purposes, the following qop_algs values are
        defined.
         * For the Confidentiality MA field:  0001 (1) = RC2-40-CBC
           (this is also defined to be the TS "DEFAULT" conf. alg.);
                                              0002 (2) = DES-CBC;
                                              0003 (3) = DES-EDE3-CBC.
         * For the Integrity MA field:        0001 (1) = RSA-MD5
           (this is also defined to be the TS "DEFAULT" int. alg.);
                                              0002 (1) = RSA-MD2.
      - the parameters validity, policy_id, and allow_policy_mapping
        are NOT USED (NULLs are therefore the only acceptable input)

   Idu_Information
      - the idu_type parameter must have a value representing a valid
        PKCS #7 content type (i.e., "Data", "SignedData",
        "EnvelopedData", "SignedAndEnvelopedData", "DigestedData, or
        "EncryptedData") or any other valid MIME type, including
        multipart (the DEFAULT value is specified to be "text/plain");
      - the idu_title parameter is NOT USED (the only acceptable input,
        therefore, is NULL)





Adams                Document Expiration:  30 Nov. 1996                3

   Prot_Information
      - the idu_type (in Idu_Information) parameter is read from the
        S/MIME P-IDU and is output by IDUP_End_Unprotect()
      - The originator_name parameter is read from the S/MIME P-IDU (the
        "signerInfos" (and possibly "certificates") field in the
        SignedData or SignedAndEnvelopedData content types) and is
        output by IDUP_End_Unprotect()
      - all other parameters are NOT USED (and therefore NULL)

   Special_Conditions
      - NOT USED (the only acceptable input, therefore, is NULL)

   Target_Info
      - this bundle is used as described in IDUP; no DEFAULT values are
        specified

   General_Service_Data
      - the unencapsulated_token parameter is used only if
        encapsulation_request is FALSE);
      - the minor_status parameter is used to return minor status values
        as specified in Section 5 below.

   Prot_Service
      - the prot_service_type parameter may have a value of "1"
        ("perform unsolicited service") or NULL (which specifies the
        DEFAULT value of "1");
      - the service_id parameter must have a value representing
        "PER_CONF" or "PER_DOA";
      - the parameters Service_Creation_Info, service_to,
        Service_Verification_Info, and service_verification_info_id are
        NOT USED (and therefore NULL)

   Unprot_Service
      - the unprot_service_type parameter will always have a value of
        "1" ("receive unsolicited service");
      - the service_id parameter will have a value representing
        "REC_CONF" or "REC_DOA";
      - the parameters service_verification_info_id,
        Service_Verification_Info, service_to, and
        Service_Creation_Info, are NOT USED (and therefore NULL)


3. SUMMARY OF TRANSFORMATIONS

   The following composition of transformations is applied to the IDU
   for full S/MIME compliance during the IDUP protection set of calls
   (see [S/MIME] for discussions of Content-Transfer-Encoding and
   Canonicalization; "PerSecServ" refers to the performance of security
   services):

     Transmit_Form = C-T-Encode(PerSecServ(Canonicalize(Local_Form)))

   The inverse transformations are performed, in reverse order, to
   unprotect the IDU ("RemSecServ" refers to the removal/verification of
   security services):

Adams                Document Expiration:  30 Nov. 1996                4

     Local_Form = DeCanonicalize(RemSecServ(C-T-Decode(Transmit_Form))).

   It is the responsibility of the underlying p7im implementation to
   perform the PerSecServ and RemSecServ transformations above.  The
   transformations Canonicalize, DeCanonicalize, C-T-Encode, and
   C-T-Decode are expected to be performed by the calling application
   unless one or more of the transformations is unnecessary (e.g., the
   input data is already in canonical form).

   Note that the Local_Form and the functions to transform messages to
   and from Canonical_Form may vary between the protector and
   unprotector systems provided there is no loss of information.



4. TOKEN FORMAT

   This section discusses protocol-visible characteristics of p7im; it
   defines elements of protocol for interoperability and is independent
   of any IDUP language bindings.

   The p7im IDUP-GSS-API mechanism will be identified by an Object
   Identifier representing "p7im" , having the value:
      { iso(1) org(3) dod(5) internet(1) security(5) p7im(xx) }
   The token transferred between IDUP-GSS-API peers (for IDU protection
   and unprotection purposes) is defined.


4.1. The Protected-IDU (P-IDU) Token

   The Protected-IDU (from the output parameters of the protection set
   of calls) is a PKCS #7 ContentInfo, which itself is BER-encoded.
   The process for creating the P-IDU from the original input data
   (the IDU) consists of the steps described in [S/MIME], Section 4.4,
   after canonicalization and before base64 encoding (with all relevant
   ASN.1 specifications as described in [PKCS7]).  Processing this
   token for the unprotection set of calls consists of the steps
   described in [S/MIME], Section 4.5 after base64 decoding and before
   de-canonicalization.

   Thus, the input to the protection set of calls is treated as an
   opaque object (which will typically be a properly-encoded MIME object
   [RFC-1521]).  This object is passed either in a single buffer to the
   IDUP_Start_Protect() call, or in multiple buffers (of arbitrary size)
   to the IDUP_Protect() call (one buffer per call).  The result is a
   properly-encoded PKCS #7 ContentInfo, which may be content-transfer-
   encoded and placed within the body of an "application/x-pkcs7-mime"
   body part to produce a properly-encoded S/MIME object.

   For unprotection, the input is assumed to be a properly-encoded
   S/MIME object (passed either as a single buffer to
   IDUP_Start_Unprotect() or as multiple buffers to IDUP_Unprotect()).
   The output is treated as an opaque object (but will typically be a
   properly-encoded MIME object, ready to be passed to a MIME parser for
   further processing.

Adams                Document Expiration:  30 Nov. 1996                5

4.2. Example of Protection Tokens

4.2.1 Signed Data

   In similar fashion to the example given in [S/MIME], Section 4.4,
   assume that the MIME object (MO) to be protected is as follows:

      Content-Type: text/plain; charset="us-ascii"

      This is a signed message.

   Using the IDUP protection set of calls with the p7im underlying
   mechanism yields the following sequence of events.

    * MO is canonicalized to have <CR><LF> end-of-line delimiters
      (this step is performed by the calling application).

    * Assuming a signing algorithm of md5-with-RSA, and assuming that
      certificates and CRLs do not need to be carried within the message
      in this particular environment, the canonicalized MIME object
      (CMO) is then signed according to PKCS #7 SignedData, so that the
      resulting ASN.1 SEQUENCE has version=1, digestAlgorithms=md5,
      contentInfo=CMO, and signerInfos={version=1,
      issuerAndSerialNumber=..., digestAlgorithm=md5,
      digestEncryptionAlgorithm=RSA, encryptedDigest=34iur8a...834rnfz}.

    * The PKCS #7 ContentInfo structure is then the ASN.1 SEQUENCE
      {contentType={pkcs-7 2}, content=SignedData}.

    * ContentInfo is then BER-encoded.

    * The BER-encoded ContentInfo is then base64-encoded
      (this step is performed by the calling application).

    * The BER-encoded, base64-encoded ContentInfo becomes the body of an
      application/x-pkcs7-mime body part.  The result might look like
      the following:
         Content-Type: application/x-pkcs7-mime
         Content-Transfer-Encoding: base64

         ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
         4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
         n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
         rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
         7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
         f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
         7GhIGfHfYT64VQbnj756
      (this step is performed by the calling application).

   This would be sent in a MIME message to the intended recipient, who
   would reverse the above process (using the IDUP unprotection set of
   calls with underlying mechanism p7im, or any other S/MIME processor)
   to retrieve the original MIME object MO.  This object can then be
   passed to the recipient's MIME parser, which will process it and
   display "This is a signed message." to the user.

Adams                Document Expiration:  30 Nov. 1996                6

5. MINOR STATUS CODES

   No minor status codes have yet been defined for S/MIM.


6. SECURITY CONSIDERATIONS

   Security issues are discussed throughout this memo.


7. REFERENCES

[IDUP]      C. Adams, "Independent Data Unit Protection Generic Security
            Service Application Program Interface (IDUP-GSS-API)",
            Internet Draft draft-ietf-cat-idup-gss.0x.txt (work in
            progress).

[IDUP-C]    D. Thakkar, D. Grebovich, "Independent Data Unit Protection
            Generic Security Service Application Program Interface:
            C-bindigs", Internet Draft draft-ietf-cat-idup-cbind-0x.txt
            (work in progress).

[KRB5]      J. Linn, "The Kerberos Version 5 GSS-API Mechanism",
            Internet Draft draft-ietf-cat-kerb5gss-0x.txt (work in
            progress).

[PKCS7]     RSA Laboratories, The Public-Key Cryptography Standards
            (PKCS) #7:  "Cryptographic Message Syntax Standard", version
            1.5, November 1, 1993.

[RFC-1508]  J. Linn, "Generic Security Service Application Program
            Interface", RFC 1508.

[RFC-1521]  N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail
            Extensions) Part One:  Mechanisms for Specifying and
            Describing the Format of Internet Message Bodies", September
            1993.

[S/MIME]    RSA Data Security, Inc., "S/MIME Message Specification:
            PKCS Security Services for MIME", Aug. 29, 1995.

[SPKM]      C. Adams, "The Simple Public-Key GSS-API Mechanism
            (SPKM)", Internet Draft draft-ietf-cat-spkmgss-0x.txt (work
            in progress).


8. AUTHOR'S ADDRESS

      Carlisle Adams
      NORTEL Secure Networks
      P.O.Box 3511, Station C
      Ottawa, Ontario, CANADA  K1Y 4H7
      Phone:  (613) 763-9008
      E-mail: cadams@bnr.ca