INTERNET-DRAFT                              Daniel R. L. Brown
draft-ietf-smime-ecc-01.txt                 Certicom Corp
14 July, 2000                               Expires:  14 January 2001

                      Use of ECC Algorithms in S/MIME

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document is the second draft of a profile for the
   incorporation of Elliptic Curve Cryptography (ECC) public key
   algorithms in the Cryptographic Message Syntax (CMS).  The ECC
   algorithms support the creation of digital signatures and the
   exchange of keys to encrypt or authenticate message content.  The
   definition of the algorithm processing is based on the ANSI X9.62
   standard and the ANSI X9.63 draft, developed by the ANSI X9F1
   working group.


















Brown              Expires January 2001          [Page 1]


Internet-Draft          Use of ECC in S/MIME     July 2000


Table of Contents

   1  Introduction ........................................ 3
      1.1  Requirement terminology ........................ 3
   2  EnvelopedData using ECC ............................. 3
      2.1  EnvelopedData using X9.63 ECDH ................. 3
           2.1.1  Fields of KeyAgreeRecipientInfo type .... 4
           2.1.2  Actions of the sending agent ............ 5
           2.1.3  Actions of the receiving agent .......... 5
      2.2  EnvelopedData using X9.63 modified ECDH ........ 5
           2.2.1  Fields of KeyAgreeRecipientInfo type .... 6
           2.2.2  Actions of the sending agent ............ 6
           2.2.3  Actions of the receiving agent .......... 6
      2.3  EnvelopedData using X9.63 1-Pass MQV ........... 7
           2.3.1  Fields of KeyAgreeRecipientInfo type .... 7
           2.3.2  Actions of the sending agent ............ 9
           2.3.3  Actions of the receiving agent .......... 9
           2.3.4  Originator certificates ................. 9
   3  AuthenticatedData using X9.63 1-Pass MQV ............ 10
      3.1  AuthenticatedData using X9.63 1-pass MQV ....... 11
           3.1.1  Fields of KeyAgreeRecipientInfo type .... 11
           3.1.2  Actions of the sending agent ............ 11
           3.1.3  Actions of the receiving agent .......... 11
           3.1.4  Originator certificates ................. 11
           3.1.5  Re-using a KEK with 1-Pass MQV .......... 11
   4  SignedData using ECC ................................ 12
      4.1  SignedData using X9.62 ECDSA ................... 12
           4.1.1  Fields of the SignedData type ........... 13
           4.1.2  Actions of the sending agent ............ 14
           4.1.3  Actions of the receiving agent .......... 14
   5  Certificates using ECC .............................. 15
   6  SMIMECapabilites Attribute and ECC .................. 15
   7  ASN.1 Types and Identifiers ......................... 15
      7.1  Object identifiers ............................. 15
      7.2  Type definitions ............................... 17
   8  Summary ............................................. 17
   References ............................................. 18
   Security Considerations ................................ 19
   Intellectual Property Rights ........................... 19
   Acknowledgments ........................................ 20
   Author's Address ....................................... 20
   Full Copyright Statement ............................... 20









Brown              Expires January 2001          [Page 2]


Internet-Draft          Use of ECC in S/MIME     July 2000


1  Introduction

   The Cryptographic Message Syntax (CMS) is cryptographic algorithm
   independent.  This specification defines a standard profile for the
   use of Elliptic Curve Cryptography (ECC) public key algorithms in
   the CMS.  The ECC algorithms are incorporated into following CMS
   content types:

      - 'EnvelopedData' to support ECC public key agreement methods
        (ECDH and MQV) to generate pairwise key-encryption keys to
        encrypt content-encryption keys used for content encryption

      - 'AuthenticatedData' to support ECC based public key agreement
        methods (MQV) to generate pairwise key-encryption keys to
        encrypt MAC keys used for content authentication

      - 'SignedData' to support ECC based digital signature methods
        (ECDSA) to sign content

   Certificates based on ECC digital signatures (ECDSA) are also
   supported.

1.1  Requirements terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119
   [MUST].

2  EnvelopedData using X9.63 ECC methods

   Elliptic curve cryptography (ECC) methods for key agreement are
   specified in [X9.63].  This specification refers to [X9.63] for the
   cryptographic operations.

   Note: all the key agreement methods here use the key derivation
   method specified in [X9.63, Section 5.6.3].

2.1  EnvelopedData using X9.63 (standard) ephemeral-static ECDH

   Ephemeral-static Elliptic Curve Diffie-Hellman (ECDH) key agreement
   algorithm is the elliptic curve analog of the Diffie-Hellman key
   agreement algorithm specified jointly in the documents [CMS,
   Section 12.3.1.1] and [DH-X9.42].  The key agreement method is
   adapted to use the elliptic curve methods from [X9.63, Section
   6.2], the "1-Pass Diffie-Hellman scheme" using the standard
   Diffie-Hellman primitive [X9.63, Section 5.4.1].



Brown              Expires January 2001          [Page 3]


Internet-Draft          Use of ECC in S/MIME     July 2000


2.1.1  Fields of KeyAgreeRecipientInfo type

   When using ephemeral-static ECDH, the EnvelopedData RecipientInfos
   KeyAgreementInfo fields must be used as follows:

      version is 3, as in [CMS, section 12.3.1.1].

      originator is the alternative originatorKey, as in [CMS, Section
      12.3.1.1].  The originatorKey algorithm fields contains the
      id-ecPublicKey object identifer with absent parameters.  The
      id-ecPublicKey object identifier is:

         id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2)
            ansi-x9-62(10045) keyType(2) 1 }

      The originatorKey publicKey field contains the sender's
      ephemeral EC public key as determined below (by methods of
      [X9.63]).

      ukm may be absent, as in [CMS, Section 12.3.1.1], and has the
      same meaning as in [CMS].

      keyEncryptionAlgorithm is the dhSinglePass-stdDH-sha1kdf-scheme
      algorithm identifier, with parameter field KeyWrapAlgorithm
      present, with the follow value and syntax:

         dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) tc68(133) country(16)
            x9(840) x9-63(63) schemes(0) 2}

         KeyWrapAlgorithm ::= AlgorithmIdentifier

      The KeyWrapAlgorithm indicates the symmetric encryption
      algorithm used to encrypt the CEK with the KEK.

      recipientEncryptedKeys contains an encrypted (wrapped)
      content-encryption key and an identifier for each recipient, as
      in [CMS, section 12.3.1.1].

   The next two sections specify actions of sending and receiving
   agents to handle ephemeral-static ECDH in keyAgreeRecipientInfo
   fields of EnvelopedData.








Brown              Expires January 2001          [Page 4]


Internet-Draft          Use of ECC in S/MIME     July 2000


2.1.2  Actions of the sending agent

   When using ephemeral-static ECDH to generate EnvelopedData
   KeyAgreeRecipientInfo fields, the sending agent selects groups of
   recipients with common EC domain parameters.  For each group, the
   sending agent selects an ephemeral EC public key pair, as per the
   1-Pass Diffie-Hellman scheme initiator transformation, specified in
   [X9.63, Section 6.2.1].  The sending agent determines an integer
   "keydatalen" from key-size of the KeyWrapAlgorithm and a bit string
   "SharedData" from the ukm field if present.  For each recipient in
   the group, the sending agent completes the X9.63 1-Pass
   Diffie-Hellman initiator transformation using the selected
   ephemeral EC public key and the recipient's static EC public key
   (i.e. from a certificate) to obtain a bit string "KeyData". The
   "KeyData" bit string becomes the pairwise key-encryption key for
   the recipient.

2.1.3  Actions of the receiving agent

   The receiving agent uses the following process on an EnvelopedData
   to detect if ephemeral-static Diffie-Hellman is used to transfer
   the CEK to the receiving agent, and if so to compute the
   key-encryption key used to unwrap the CEK.

   The receiving agent determines the bit string "SharedData" from the
   ukm field if present, and the integer "keydatalen" from the
   key-size of the KeyWrapAlgorithm and completes the X9.63 1-Pass
   Diffie-Hellman responder transformation [X9.63, Section 6.2.2],
   using the ephemeral EC public key and the identified receiving
   agent's static EC public key, to obtain a bit string "KeyData".
   The "KeyData" bit string becomes the pairwise key-encryption key
   for the receiving agent.

2.2  EnvelopedData using X9.63 modified ephemeral-static ECDH

   Modified ephemeral-static Elliptic Curve Diffie-Hellman (ECDH) key
   agreement algorithm is identical to standard ECDH except that a
   modified version of the Diffie-Hellman primitive [X9.63, Section
   5.4.2] is used. The modification involves multiplication by a
   cofactor.  A purpose of the modification is to prevent the
   small-subgroup attack [SSG].  To indicate that the modified
   Diffie-Hellman primitive is used, a different algorithm identifider
   for this key agreement algorithm is provided, as specified below.







Brown              Expires January 2001          [Page 5]


Internet-Draft          Use of ECC in S/MIME     July 2000


2.2.1  Fields of KeyAgreeRecipientInfo type

   When using modified ephemeral-static ECDH, the EnvelopedData
   RecipientInfos KeyAgreementInfo fields are the same as in those
   specified in Section 2.1.1 of this document, except:

      keyEncryptionAlgorithm is the
      dhSinglePass-cofactorDH-sha1kdf-scheme algorithm identifier,
      with parameter KeyWrapAlgorithm present, and the following value
      and syntax:

         dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::=
            { iso(1) identified-organization(3) tc68(133) country(16)
            x9(840) x9-63(63) schemes(0) 3}

         KeyWrapAlgorithm ::= AlgorithmIdentifier

2.2.2  Actions of the sending agent

   The actions of the sending agent are identical to the actions of
   sending agent using standard ephemeral-static ECDH specified above
   in Section 2.1.2, except that:

      - The sending agent uses the modified Diffie-Hellman primitive
        of [X9.63, Section 5.4.2] rather than the standard
        Diffie-Hellman primitive [X9.63, Section 5.4.1].

   Note: modified and standard ephemeral-static ECDH can only be used
   within separate KeyAgreeRecipientInfo fields.

2.2.3  Actions of the receiving agent

   The actions of the receiving agent are identical to the actions of
   receiving agent using standard ephemeral-static ECDH specified
   above in Section 2.1.2, except that:

      - The receiving agent uses the modified Diffie-Hellman primitive
        of [X9.63, Section 5.4.2] rather than the standard
        Diffie-Hellman primitive [X9.63, Section 5.4.1].











Brown              Expires January 2001          [Page 6]


Internet-Draft          Use of ECC in S/MIME     July 2000


2.3  EnvelopedData using X9.63 1-Pass MQV

   In [X9.63, Appendix H.4.5], 1-Pass MQV is suggested for
   store-and-forward applications such as e-mail.

   The 1-Pass MQV key agreement method, specified in [X9.63, Section
   6.9], uses three EC public keys to generate keying data
   (i.e. pairwise key-encryption key).  The three keys are: a static
   recipient key, a static originator key, and an ephemeral originator
   key.

   The originator's static EC public key is identified in the
   originator field, usually by reference to a certificate.  The
   originator's ephemeral EC public is specified within the ukm field.
   The recipient's static EC public key is identified according to
   [CMS], within a rid field.

2.3.1  Fields of KeyAgreeRecipientInfo type

   When using 1-Pass MQV, the EnvelopedData RecipientInfos
   KeyAgreementInfo fields are used as follows:

      version is 3, as in [CMS, section 12.3.1.1].

      originator identifies the static EC public key of the sender.
      It should be the one of the alternatives issuerAndSerialNumber
      or subjectKeyIdentifier and point to one of the sender's
      certificates supplied in the EnvelopedData originatorInfo field.
      (If necessary, it may be the alternative originatorKey, as in
      [CMS, Section 12.3.1.1], and if so, the originatorKey algorithm
      field contains the id-ecPublicKey object identifer with absent
      parameters.  The id-ecPublicKey object identifier is:

         id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2)
            ansi-x9-62(10045) keyType(2) 1 }

      The originatorKey publicKey field contains the sender's static
      EC public key.)












Brown              Expires January 2001          [Page 7]


Internet-Draft          Use of ECC in S/MIME     July 2000

      ukm is present.  It identifies the ephemeral EC public key of
      the sender.  It may also identify some additional information
      for purposes similar to those specified in [CMS, Section
      12.3.1.1].  The ukm field contains an octet string which is the
      DER encoding of the following ASN.1 type

         MQVuserKeyingMaterial ::= SEQUENCE {
            ephemeralPublicKey OriginatorPublicKey,
            addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }

         The MQVuserKeyingMaterial ephemeralPublicKey algorithm field
         contains the id-ecPublicKey object identifer with absent
         parameters.  The id-ecPublicKey object identifier is:

            id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1)
               member-body(2) ansi-x9-62(10045) keyType(2) 1 }

         The MQVuserKeyingMaterial ephemeralPublicKey publicKey field
         contains the sender's ephemeral EC public key as determined
         below (by methods of [X9.63]).  The MQVuserKeyingMaterial
         addedukm field, if present, contains an octet string, whose
         meaning is similar to meaning of the ukm field in [CMS,
         Section 12.3.1.1].

      keyEncryptionAlgorithm is the mqvSinglePass-sha1kdf-scheme
      algorithm identifier, with parameter field KeyWrapAlgorithm
      present, with the following values and syntax:

         mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
            identified-organization(3) tc68(133) country(16) x9(840)
            x9-63(63) schemes(0) 16}

         KeyWrapAlgorithm ::= AlgorithmIdentifier

      The KeyWrapAlgorithm indicates the symmetric encryption
      algorithm used to encrypt the CEK with the KEK generated using
      the 1-Pass MQV algorithm.

      recipientEncryptedKeys contains an encrypted (wrapped)
      content-encryption key and an identifier for each recipient, as
      in [CMS, section 12.3.1.1].










Brown              Expires January 2001          [Page 8]


Internet-Draft          Use of ECC in S/MIME     July 2000


2.3.2  Actions of the sending agent

   When using 1-Pass MQV to generate EnvelopedData
   KeyAgreeRecipientInfo fields, the sending agent selects groups of
   recipients with common EC domain parameters.  For each group, the
   sending agent selects an ephemeral EC public key pair, as per the
   1-Pass MQV scheme initiator transformation, specified in [X9.63,
   Section 6.9.1].  The sending agent specifies the ephemeral EC
   public key in the KeyAgreeRecipientInfo ukm field, ASN.1 encoded
   within in the MQVuserKeyingMaterial ephemeralPublickey publicKey
   field.  The sending agent determines an integer "keydatalen" from
   key-size of the KeyWrapAlgorithm and a bit string "SharedData" from
   the MQVuserKeyingMaterial addedukm field (if present) ASN.1 encoded
   in the ukm field.  For each recipient in the group, the sending
   agent completes the 1-Pass MQV initiator transformation using the
   selected ephemeral EC public key pair, the static EC public keys
   (i.e. from certificates) of the originator and the recipient, and
   the bit string "SharedData" if present, to obtain a bit string
   "KeyData".  The bit string "KeyData" becomes the pairwise
   key-encryption key (KEK) for the recipient.

2.3.3  Actions of the receiving agent

   The receiving agent uses the following process on an EnvelopedData
   to detect if 1-Pass MQV is used to agree on the pairwise KEK for
   the receiving agent, and if so to compute the pairwise KEK.

   The receiving agent determines the bit string "SharedData" from the
   ukm field if present, and the integer "keydatalen" from the
   key-size of the KeyWrapAlgorithm and completes the 1-Pass MQV
   responder transformation [X9.63, Section 6.9.2], using the
   ephemeral EC public key, the identified static EC public keys of
   the recipient and originator, and the bit string "SharedData" if
   present, to obtain a bit string "KeyData".  The bit string
   "KeyData" becomes the the pairwise key-encryption key (KEK) for the
   receiving agent.

2.3.4  Originator's certificates

   If some recipients do not have other means to obtain the
   originator's certificate for a static EC public key used in 1-Pass
   MQV, then the originator's certificate containing the originator
   static EC public key should be included in the EnvelopedData
   originatorInfo field.






Brown              Expires January 2001          [Page 9]


Internet-Draft          Use of ECC in S/MIME     July 2000


3  AuthenticatedData using ECC

   The 1-Pass MQV scheme of [X9.63] has been selected in this document
   for AuthenticatedData using ECC because it has security attributes
   that are appropriate for the AuthenticatedData CMS type.

   Note: in general, pure 'ephemeral-static' key agreement methods are
   not suitable for AuthenticatedData because the originator's key is
   ephemeral and therefore not authenticated.

   Note: both SignedData and AuthenticatedData provide assurance to
   the receiving agent that the content data originated from the
   purported originator and the content was in no way modified.
   However, SignedData and AuthenticatedData differ in some important
   respects:

      1.  In AuthenticatedData the assurance of the content origin and
      integrity is only provided to the specific recipients of the
      AuthenticatedData.  In SignedData, the assurance of content
      origin and integrity is provided to potentially everyone.

      2.  In AuthenticatedData, the sending agent and receiving agent
      are equally capable producing any given AuthenticatedData.  In
      SignedData, only the sending agent is capable of producing the
      SignedData.

   Careful consideration should be applied to the choice of using
   AuthenticatedData or SignedData because of the these differences.
   In particular, in AuthenticatedData the originator has less
   'commitment' to the content than SignedData because
   AuthenticatedData does not have the non-repudiative feature of
   SignedData.

3.1  AuthenticatedData using 1-pass MQV

   In general, using 1-Pass MQV in AuthenticatedData is similar to
   using 1-Pass MQV in EnvelopedData (see Section 2.3 of this
   document).  Further details are provided in Sections 3.1.1 to
   3.1.4.

   However, 1-Pass MQV, AuthenticatedData and EnvelopedData can be use
   together more efficiently by the re-using pairwise key-encryption
   keys.  A method to do this is specified in Section 3.1.5.





Brown              Expires January 2001          [Page 10]


Internet-Draft          Use of ECC in S/MIME     July 2000


3.1.1  Fields of the KeyAgreementInfo type

   The AuthenticatedData KeyAgreeRecipientInfo fields are used in the
   same manner as the fields for the corresponding EnvelopedData
   KeyAgreeRecipeintInfo fields of Section 2.3.1 of this document.

   Note: the originator field should be one of the alternatives
   issuerAndSerialNumber or subjectKeyIdentifier.  If it is necessary
   to use the originatorKey alternative, the recipients should have
   other means (i.e. without certificates) to authenticate the
   originator's static key.

3.1.2  Actions of the sending agent

   The sending agent may use the same actions as for EnvelopedData
   with 1-Pass MQV, as specified in Section 2.3.2 of this document.

3.1.3  Actions of the receiving agent

   The receiving agent may use the same actions as for EnvelopedData
   with 1-Pass MQV, as specified in Section 2.3.3 of this document.

3.1.4  Originator certificates

   If some recipients do not have other means to obtain the
   originator's certificate for a static EC public key used in 1-Pass
   MQV, then the originator's certificate certifying the originator
   static EC public key should be included in the AuthenticatedData
   originatorInfo field.

   For recipients that do not have other measn to obtain all the issue
   certificates necessary to authenticate the originator's static EC
   public key, then the necessary certificates (i.e. CA
   cross-certifcates) may be included in the AuthenticatedData
   originatorInfo field.

3.1.5  Re-using a KEK with 1-Pass MQV

   When using 1-Pass MQV for an AuthenticatedData whose content is an
   EnvelopedData, or for an AuthenticatedData which is the content is
   an EnvelopedData, the KEKRecipientInfo type of [CMS] is an
   efficient way to re-use a 1-Pass MQV generated pairwise KEK from
   the EnvelopedData.  Re-use of the EnvelopedData KEK helps to reduce
   the total length of the ASN.1 encoding of the AuthenticatedData and
   the total number of public key cryptographic operations performed
   by both sending agents and receiving agents.




Brown              Expires January 2001          [Page 11]


Internet-Draft          Use of ECC in S/MIME     July 2000


   The KEKRecipientInfo encryptedKey field contains the wrapped "MAC"
   key, encrypted with the previously generated KEK using 1-Pass MQV.
   Generally, the pairwise KEK will have been generated within an
   EnvelopedData.  The KEKRecipientInfo KEKIdentifier keyIdentifier
   field may be used to identify the re-used secret pairwise KEK
   by providing an octet encoding of the originator's ephemeral EC
   public key used in a 1-Pass MQV to to generate the KEK.

   The KEKIdentifier other field may be absent, if it is certain that
   the KEK is unambiguously identified.  If the KEKIdentifier
   keyIdentifier field alone is insufficient to identify the KEK
   (perhaps because the receiving agent supports other methods that
   use KEKReicipientInfo) then the KEKIdentifier other keyAttrId
   field may be object identifier mqvSinglePass-sha1kdf-scheme (see
   Section 2.3.1 of this document).

   Note: if the content of the AuthenticatedData is an EnvelopedData,
   then the KeyAgreeRecipientInfo fields of the EnvelopedData are in
   plaintext and therefore, the KEK can be computed before the
   EnvelopedData is decrypted or encrypted.  If the content of an
   EnvelopedData is an AuthenticatedData the KEK will be computed
   before the AuthenticatedData is encrypted or decrypted.  In the
   either case, both the sending agent and receiving agent are able to
   determine the necessary KEK from the EnvelopedData.

4  SignedData using ECC

   An elliptic curve cryptography (ECC) method for signing is
   specified in [X9.62].  In a single SignedData type [CMS] many
   signing algorithms may be used but within each SignerInfo field
   only one signing algorithm can be used.

4.1  SignedData using X9.62 ECDSA

   The Elliptic Curve Digital Signature Algorithm (ECDSA) is specified
   in [X9.62].  The method is the elliptic curve analog of the [X9.30]
   Digital Signature Algorithm (DSA).  In [CMS] the meanings of the
   fields of SignedData are specified, the actions of the sending
   agent to generate SignedData are specified and the actions of the
   receiving agent to process SignedData are specified.  In [CMS], the
   specificiations are algorithm independent.  The following
   subsections provide additional details about the SignedData fields
   and actions of S/MIME agents when [X9.62] ECDSA is being used with
   SignedData.






Brown              Expires January 2001          [Page 12]


Internet-Draft          Use of ECC in S/MIME     July 2000


4.1.1  Fields of the SignedData type

   When using [X9.62] ECDSA in an SignedData SignerInfo type the
   fields are as in [CMS], but with the following restrictions.

      digestAlgorithm is the following algorithm identifier for SHA-1:

         sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
            oiw(14) secsig(3) algorithm(2) 26 }

      signatureAlgorithm is an algorithm identifer with parameters
      field absent that identifies the ECDSA signature algorithm with
      the object identifier:

         ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
            us(840) 10045 signatures(4) 1 }

      signature is the DER encoding (as an octet string) of a value of
      the [X9.62] ASN.1 type:

         ECDSA-Sig-Value ::= SEQUENCE {
            r INTEGER,
            s INTEGER }

      where the integers r and s are caculated according to [X9.62,
      Section 5.3] using the signer's private key except that the
      integer "e" is the result of the SignedData message digest
      specified in [CMS] converted from an octet string to an intger
      (i.e. not the result of [X9.63, Section 5.3.1]).

   When using [X9.62] ECDSA the SignedData certificates field may
   include the certificates for the EC public keys used in generation
   of ECDSA signatures in the SignedData.  If it is expected that
   recipients have alternative means of obtaining the certain
   certificates necessary to authenticate the EC public keys used for
   signing, then such certificates may be omitted from the SignedData
   certificates field.  All certificates necessary for the
   authentication of the EC public keys using for signing for which it
   is not expected that the recipients have alternative means of
   obtaining should be included in the SignedData certificates field.










Brown              Expires January 2001          [Page 13]


Internet-Draft          Use of ECC in S/MIME     July 2000


4.1.2  Actions of the sending agent

   The sending agent uses the message digest calculation process and
   signature generation process for SignedData that are specified in
   [CMS].  The sending agent follows the actions for ECDSA signature
   generation specified in [X9.62, Section 5.3] with the following
   exceptions:

      - In [X9.62, Section 5.3.1], the integer "e" shall instead
        be determined by converting the octet string resulting from
        [CMS, Section 5.4] to an integer using the data conversion
        method in [X9.62, Section 4.3.2].

   The sending agent uses the encoding process specified [X9.62,
   Section 6.5] to convert (encode) the ECDSA signature as an octet
   string.  This octet string is the value of the SignerInfo
   SignatureValue field.  The sending agent uses DER encoding rules
   and includes the entire encoding of the ASN.1 type ECDSA-Sig-Value
   (see above and [X9.62]) including the tag and length octets in the
   octet string SignerInfo SignatureValue.

4.1.3  Actions of the receiving agent

   The receiving agent uses the message digest calculation process
   and signature verification process for SignedData that are
   specified in [CMS].  The receiving agent follows the actions
   for ECDSA signature verification specified in [X9.62, Section 5.4]
   with the following exceptions:

      - In [X9.62, Section 5.4.1] the integer "e" shall instead be
        determined by converting the octet string resulting from [CMS,
        Section 5.4] to an integer using the data conversion method in
        [X9.62, Section 4.3.2].

   The receiving agent uses the encoding process specified in [X9.62,
   Section 6.5] to convert (decode) the octet string value of the
   SignerInfo SignatureValue field to the [X9.62] signature.  The
   receiving agent uses DER decoding rules.












Brown              Expires January 2001          [Page 14]


Internet-Draft          Use of ECC in S/MIME     July 2000


5  Certificates using ECC

   The use of a certificates with ECC is specified in [EPKIX].
   Further information on the use ECC with certificates is given in
   [SECG-WG-EC].

6  SMIMECapabilities Attribute and ECC

   A sending agent may choose to announce to receiving agents that it
   supports one or more of the ECC algorithms in this document by
   using SMIMECapabilities signed attribute as specified in [MSG,
   Section 2.5.2].

   The SMIMECapability capabilityID object identifiers for the
   supported key agreement algorithms in this document are
   dhSinglePass-stdDH-sha1kdf-scheme,
   dhSinglePass-cofactorDH-sha1kdf-scheme, and
   mqvSinglePass-sha1kdf-scheme.  For each of these SMIMECapability
   SEQUENCEs the parameters field is present and indicates the
   supported key-encryption algorithm with the KeyWrapAlgorithm
   algorithm identifier.

   The SMIMECapability value to indicate support for the ECDSA
   signature algorithm is the SEQUENCE with the capabilityID field
   containing the object identifier ecdsa-with-SHA1 and the parameters
   field absent.

7  ASN.1 Types and Identifiers

   The ASN.1 types and object identifiers that are used in this
   document are gathered together in this section for reference
   purposes.

7.1  Object identifiers

   The object identifiers used in this document are taken from [CMS],
   [X9.63] and [X9.62].













Brown              Expires January 2001          [Page 15]


Internet-Draft          Use of ECC in S/MIME     July 2000


   The following object identifiers indicate the key agreement
   algorithms used in this document:

      dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) tc68(133) country(16) x9(840)
         x9-63(63) schemes(0) 2}

      dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
         iso(1) identified-organization(3) tc68(133) country(16)
         x9(840) x9-63(63) schemes(0) 3}

      mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) tc68(133) country(16) x9(840)
         x9-63(63) schemes(0) 16}

   The following object identifier indicates the digital signature
   algorithm used in this document:

      ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) 10045 signatures(4) 1 }

   The following object identifier indicates the hash algorithm used
   in this document:

      sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
         oiw(14) secsig(3) algorithm(2) 26 }

   The following object identifier is used in this document to
   indicate an elliptic curve public key:

      id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         ansi-x9-62(10045) keyType(2) 1 }


















Brown              Expires January 2001          [Page 16]


Internet-Draft          Use of ECC in S/MIME     July 2000


7.2  Type definitions

   The following ASN.1 type defintions are used.

      ECDSA-Sig-Value ::= SEQUENCE {
         r INTEGER,
         s INTEGER }

      MQVuserKeyingMaterial ::= SEQUENCE {
         ephemeralPublicKey OriginatorPublicKey,
         addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL  }

   The former is taken from [X9.62].  In this document, DER encodings
   as octet strings of values of the two above ASN.1 types
   ECDSA-Sig-Value and MQVuserKeyingMaterial are used as values of
   octet string ASN.1 types from [CMS].  An encoding of
   ECDSA-Sig-Value is used as the value of a SignedData SignerInfo
   SignatureValue and an encoding of MQVuserKeyingMaterial is used as
   the value of EnvelopedData KeyAgreeRecipeintInfo UserKeyingMaterial
   or AuthenticatedData KeyAgreeRecipeintInfo UserKeyingMaterial.

8  Summary

   This document specifies how to use ECC methods with S/MIME CMS
   type.  The most notable advantage of ECC methods over integer
   arithmetic based methods (Diffie-Hellman, DSA and RSA) is the
   shorter length of cryptographic overhead in signatures,
   certificates, encrypted and authenticated messages..

   This document specifies a cryptographic method to be used with the
   [CMS] content type AuthenticatedData.  The cryptographic method is
   X9.63 1-Pass MQV scheme.  The AuthenticateData type achieves
   authentication without 'non-repudiation'.  For certain kinds of
   data, AuthenticatedData may be preferrable to SignedData.
















Brown              Expires January 2001          [Page 17]


Internet-Draft          Use of ECC in S/MIME     July 2000


References

   [CMS]       R. Housley, "Cryptographic Message Syntax", RFC 2630,
               June 1999.

   [DH-X9.42]  E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC
               2631, June 1999.

   [EPKIX]     L. Bassham and D. Johnson, "Internet X.509 Public Key
               Infrastructure Representation of Elliptic Curve Digital
               Signature Algorithm (ECDSA) Keys and Signatures in
               Internet X.509 Public Key Infrastructure Certificates",
               PKIX Working Group Internet-Draft, October, 1999.

   [FIPS-180]  Federal Information Processing Standards Publication
               (FIPS PUB) 180-1, "Secure Hash Standard", 1995 April
               17.

   [FIPS-186]  Federal Information Processing Standards Publication
               (FIPS PUB) 186, "Digital Signature Standard", 1994 May
               19.

   [GEC1]      Certicom Research, "Guidelines for Efficinet
               Cryptography", GEC1, February, 1999.

   [KEA]       J. Pawling, "CMS KEA and SKIPJACK Conventions", S/MIME
               Working Group Internet-Draft, December, 1999.

   [LAW98]     L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone,
               "An efficient protocol for authenticated key
               agreement", Technical report CORR 98-05, University of
               Waterloo, 1998.

   [LL97]      C.H. Lim and P.J. Lee, "A key recovery attack on
               discrete log-based schemes using a prime order
               subgroup", B.S.  Kaliski, Jr., editor, Advances in
               Cryptology - Crypto '97, Lecture Notes in Computer
               Science, vol. 1295, 1997, Springer-Verlag, pp. 249-263.

   [MSG]       B. Ramsdell, "S/MIME Version 3 Message Specification",
               RFC 2633, June 1999.

   [MUST]      S. Bradner, "Key Words for Use in RFCs to Indicate
               Requirement Levels", RFC 2119, March 1997.






Brown              Expires January 2001          [Page 18]


Internet-Draft          Use of ECC in S/MIME     July 2000


   [NIST-ECC]  National Institute for Standards and Technology,
               "Recommended Elliptic Curves for Federal Government
               Use", July 1999,
               <http://csrc.nist.gov/encryption/NISTReCur.pdf>

   [IEEE1363]  IEEE, "Standard Specifications for Public Key
               Cryptography", IEEE 1363-2000 Specification, 2000,
               Annex D.

   [SEC1]      Certicom Research, "Elliptic Curve Cryptography", SEC1,
               February, 1999.

   [SEC-WG-EC] Certicom Research, "ECC in X.509", SEC X.509 Working
               Group Draft, August, 1999.

   [SSG]       R. Zuccherato, "Methods for Avoiding the Small-Subgroup
               Attacks on the Diffie-Hellman Key Agreement Method for
               S/MIME", RFC 2785, March 2000.

   [X9.30]     ANSI X9.30-1995, Part 1, "Public key cryptography using
               irreversible algorithms for the financial services
               industry: The Digital Signature Algorithm (Revised)",
               1995.

   [X9.42]     "Agreement Of Symmetric Keys Using Diffie-Hellman and
               MQV Algorithms", ANSI draft, May 1999.

   [X9.62]     ANSI X9.62-1999, "Public Key Cryptography For The
               Financial Services Industry: The Elliptic Curve Digital
               Signature Algorithm (ECDSA)", 1999.

   [X9.63]     "Public Key Cryptography For The Financial Services
               Industry: Key Agreement and Key Transport Using
               Elliptic Curve Cryptography", Draft ANSI X9F1, October
               1999.

Security Considerations

   This specification is based on [CMS], [X9.62] and [X9.63] and the
   appropriate security considerations of those documents apply.

Intellectual Property Rights

   This specification is based on ANSI specification X9.62 and X9.63.
   A variety of patent statements in these working may apply to this
   specification.  A later draft will attempt to identify a reference
   for the ANSI X9F1 related claims.



Brown              Expires January 2001          [Page 19]


Internet-Draft          Use of ECC in S/MIME     July 2000


Acknowledgments

   The key agreement methods described in this document is based on
   work done by the ANSI X9F1 working group. The author wishes to
   extend his thanks for their assistance.

   The author also wishes to thank Paul Lambert, Simon Blake-Wilson,
   and Peter de Rooij for their patient assistance.  The basis of this
   work is derived from the ANSI X9F1 working group and their
   specifications for ECDSA and EC key agreement techniques.

Author's Address

   Daniel R. L. Brown
   Certicom Corp
   5520 Explorer Drive #400
   Mississauga, ON L4W 5L1

   EMail: dbrown@certicom.com

Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain
   it or assist in its implementation may be prepared, copied,
   published and distributed, in whole or in part, without restriction
   of any kind, provided that the above copyright notice and this
   paragraph are included on all such copies and derivative works.
   However, this document itself may not be modified in any way, such
   as by removing the copyright notice or references to the Internet
   Society or other Internet organizations, except as needed for the
   purpose of developing Internet standards in which case the
   procedures for copyrights defined in the Internet Standards process
   must be followed, or as required to translate it into languages
   other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on
   an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Brown              Expires January 2001          [Page 20]