diff --git a/const-oid/oiddbgen/rfc5753.txt b/const-oid/oiddbgen/rfc5753.txt
new file mode 100644
index 000000000..9c7962e34
--- /dev/null
+++ b/const-oid/oiddbgen/rfc5753.txt
@@ -0,0 +1,3419 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         S. Turner
+Request for Comments: 5753                                          IECA
+Obsoletes: 3278                                                 D. Brown
+Category: Informational                                         Certicom
+ISSN: 2070-1721                                             January 2010
+
+
+          Use of Elliptic Curve Cryptography (ECC) Algorithms
+                 in Cryptographic Message Syntax (CMS)
+
+Abstract
+
+   This document describes how to use 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 content.  The definition
+   of the algorithm processing is based on the NIST FIPS 186-3 for
+   digital signature, NIST SP800-56A and SEC1 for key agreement, RFC
+   3370 and RFC 3565 for key wrap and content encryption, NIST FIPS
+   180-3 for message digest, SEC1 for key derivation, and RFC 2104 and
+   RFC 4231 for message authentication code standards.  This document
+   obsoletes RFC 3278.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5753.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+
+
+
+Turner & Brown                Informational                     [Page 1]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Requirements Terminology ...................................3
+   2. SignedData Using ECC ............................................3
+      2.1. SignedData Using ECDSA .....................................4
+   3. EnvelopedData Using ECC Algorithms ..............................5
+      3.1. EnvelopedData Using (ephemeral-static) ECDH ................5
+      3.2. EnvelopedData Using 1-Pass ECMQV ...........................8
+   4. AuthenticatedData and AuthEnvelopedData Using ECC ..............11
+      4.1. AuthenticatedData Using 1-Pass ECMQV ......................11
+      4.2. AuthEnvelopedData Using 1-Pass ECMQV ......................12
+   5. Certificates Using ECC .........................................13
+   6. SMIMECapabilities Attribute and ECC ............................13
+   7. ASN.1 Syntax ...................................................21
+      7.1. Algorithm Identifiers .....................................21
+      7.2. Other Syntax ..............................................24
+   8. Recommended Algorithms and Elliptic Curves .....................26
+   9. Security Considerations ........................................28
+   10. IANA Considerations ...........................................33
+   11. References ....................................................33
+      11.1. Normative References .....................................33
+      11.2. Informative References ...................................35
+   Appendix A.  ASN.1 Modules.........................................37
+      A.1.  1988 ASN.1 Module.........................................37
+      A.2.  2004 ASN.1 Module.........................................45
+   Appendix B. Changes since RFC 3278.................................59
+   Acknowledgements...................................................61
+
+
+
+
+
+Turner & Brown                Informational                     [Page 2]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+1.  Introduction
+
+   The Cryptographic Message Syntax (CMS) is cryptographic algorithm
+   independent.  This specification defines a profile for the use of
+   Elliptic Curve Cryptography (ECC) public key algorithms in the CMS.
+   The ECC algorithms are incorporated into the following CMS content
+   types:
+
+   -  'SignedData' to support ECC-based digital signature methods
+      (ECDSA) to sign content;
+
+   -  'EnvelopedData' to support ECC-based public key agreement methods
+      (ECDH and ECMQV) to generate pairwise key-encryption keys to
+      encrypt content-encryption keys used for content encryption;
+
+   -  'AuthenticatedData' to support ECC-based public key agreement
+      methods (ECMQV) to generate pairwise key-encryption keys to
+      encrypt message-authentication keys used for content
+      authentication and integrity; and
+
+   -  'AuthEnvelopedData' to support ECC-based public key agreement
+      methods (ECMQV) to generate pairwise key-encryption keys to
+      encrypt message-authentication and content-encryption keys used
+      for content authentication, integrity, and encryption.
+
+   Certification of EC public keys is also described to provide public
+   key distribution in support of the specified techniques.
+
+   The document will obsolete [CMS-ECC].  The technical changes
+   performed since RFC 3278 are detailed in Appendix B.
+
+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 [MUST].
+
+2.  SignedData Using ECC
+
+   This section describes how to use ECC algorithms with the CMS
+   SignedData format to sign data.
+
+
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                     [Page 3]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+2.1.  SignedData Using ECDSA
+
+   This section describes how to use the Elliptic Curve Digital
+   Signature Algorithm (ECDSA) with SignedData.  ECDSA is specified in
+   [FIPS186-3].  The method is the elliptic curve analog of the Digital
+   Signature Algorithm (DSA) [FIPS186-3].  ECDSA is used with the Secure
+   Hash Algorithm (SHA) [FIPS180-3].
+
+   In an implementation that uses ECDSA with CMS SignedData, the
+   following techniques and formats MUST be used.
+
+2.1.1.  Fields of the SignedData
+
+   When using ECDSA with SignedData, the fields of SignerInfo are as in
+   [CMS], but with the following restrictions:
+
+   -  digestAlgorithm MUST contain the algorithm identifier of the hash
+      algorithm (see Section 7.1.1), which MUST be one of the following:
+      id-sha1, id-sha224, id-sha256, id-sha384, or id-sha512.
+
+   -  signatureAlgorithm contains the signature algorithm identifier
+      (see Section 7.1.3): ecdsa-with-SHA1, ecdsa-with-SHA224, ecdsa-
+      with-SHA256, ecdsa-with-SHA384, or ecdsa-with-SHA512.  The hash
+      algorithm identified in the name of the signature algorithm MUST
+      be the same as the digestAlgorithm (e.g., digestAlgorithm is id-
+      sha256 therefore signatureAlgorithm is ecdsa-with-SHA256).
+
+   -  signature MUST contain the DER encoding (as an octet string) of a
+      value of the ASN.1 type ECDSA-Sig-Value (see Section 7.2).
+
+   When using ECDSA, the SignedData certificates field MAY include the
+   certificate(s) for the EC public key(s) used in the generation of the
+   ECDSA signatures in SignedData.  ECC certificates are discussed in
+   Section 5.
+
+2.1.2.  Actions of the Sending Agent
+
+   When using ECDSA with SignedData, the sending agent uses the message
+   digest calculation process and signature generation process for
+   SignedData that are specified in [CMS].  To sign data, the sending
+   agent uses the signature method specified in [FIPS186-3].
+
+   The sending agent encodes the resulting signature using the ECDSA-
+   Sig-Value syntax (see Section 7.2) and places it in the SignerInfo
+   signature field.
+
+
+
+
+
+
+Turner & Brown                Informational                     [Page 4]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+2.1.3.  Actions of the Receiving Agent
+
+   When using ECDSA with SignedData, the receiving agent uses the
+   message digest calculation process and signature verification process
+   for SignedData that are specified in [CMS].  To verify SignedData,
+   the receiving agent uses the signature verification method specified
+   in [FIPS186-3].
+
+   In order to verify the signature, the receiving agent retrieves the
+   integers r and s from the SignerInfo signature field of the received
+   message.
+
+3.  EnvelopedData Using ECC Algorithms
+
+   This section describes how to use ECC algorithms with the CMS
+   EnvelopedData format.
+
+   This document does not specify the static-static ECDH, method C(0,2,
+   ECC CDH) from [SP800-56A].  Static-static ECDH is analogous to
+   static-static DH, which is specified in [CMS-ALG].  Ephemeral-static
+   ECDH and 1-Pass ECMQV were specified because they provide better
+   security due to the originator's ephemeral contribution to the key
+   agreement scheme.
+
+3.1.  EnvelopedData Using (ephemeral-static) ECDH
+
+   This section describes how to use the ephemeral-static Elliptic Curve
+   Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData.
+   This algorithm has two variations:
+
+   - 'Standard' ECDH, described as the 'Elliptic Curve Diffie-Hellman
+     Scheme' with the 'Elliptic Curve Diffie-Hellman Primitive' in
+     [SEC1], and
+
+   - 'Co-factor' ECDH, described as the 'One-Pass Diffie-Hellman scheme'
+     (method C(1, 1, ECC CDH)) in [SP800-56A].
+
+   Both variations of ephemeral-static ECDH are elliptic curve analogs
+   of the ephemeral-static Diffie-Hellman key agreement algorithm
+   specified jointly in the documents [CMS-ALG] and [CMS-DH].
+
+   If an implementation uses ECDH with CMS EnvelopedData, then the
+   following techniques and formats MUST be used.
+
+   The fields of EnvelopedData are as in [CMS]; as ECDH is a key
+   agreement algorithm, the RecipientInfo kari choice is used.
+
+
+
+
+
+Turner & Brown                Informational                     [Page 5]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+3.1.1.  Fields of KeyAgreeRecipientInfo
+
+   When using ephemeral-static ECDH with EnvelopedData, the fields of
+   KeyAgreeRecipientInfo are as follows:
+
+   -  version MUST be 3.
+
+   -  originator MUST be the alternative originatorKey.  The
+      originatorKey algorithm field MUST contain the id-ecPublicKey
+      object identifier (see Section 7.1.2).  The parameters associated
+      with id-ecPublicKey MUST be absent, ECParameters, or NULL.  The
+      parameters associated with id-ecPublicKey SHOULD be absent or
+      ECParameters, and NULL is allowed to support legacy
+      implementations.  The previous version of this document required
+      NULL to be present.  If the parameters are ECParameters, then they
+      MUST be namedCurve.  The originatorKey publicKey field MUST
+      contain the DER encoding of the value of the ASN.1 type ECPoint
+      (see Section 7.2), which represents the sending agent's ephemeral
+      EC public key.  The ECPoint in uncompressed form MUST be
+      supported.
+
+   -  ukm MAY be present or absent.  However, message originators SHOULD
+      include the ukm.  As specified in RFC 3852 [CMS], implementations
+      MUST support ukm message recipient processing, so interoperability
+      is not a concern if the ukm is present or absent.  The ukm is
+      placed in the entityUInfo field of the ECC-CMS-SharedInfo
+      structure.  When present, the ukm is used to ensure that a
+      different key-encryption key is generated, even when the ephemeral
+      private key is improperly used more than once, by using the ECC-
+      CMS-SharedInfo as an input to the key derivation function (see
+      Section 7.2).
+
+   -  keyEncryptionAlgorithm MUST contain the object identifier of the
+      key-encryption algorithm, which in this case is a key agreement
+      algorithm (see Section 7.1.4).  The parameters field contains
+      KeyWrapAlgorithm.  The KeyWrapAlgorithm is the algorithm
+      identifier that indicates the symmetric encryption algorithm used
+      to encrypt the content-encryption key (CEK) with the key-
+      encryption key (KEK) and any associated parameters (see Section
+      7.1.5).  Algorithm requirements are found in Section 8.
+
+   -  recipientEncryptedKeys contains an identifier and an encrypted key
+      for each recipient.  The RecipientEncryptedKey
+      KeyAgreeRecipientIdentifier MUST contain either the
+      issuerAndSerialNumber identifying the recipient's certificate or
+      the RecipientKeyIdentifier containing the subject key identifier
+      from the recipient's certificate.  In both cases, the recipient's
+      certificate contains the recipient's static ECDH public key.
+
+
+
+Turner & Brown                Informational                     [Page 6]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+      RecipientEncryptedKey EncryptedKey MUST contain the content-
+      encryption key encrypted with the ephemeral-static, ECDH-generated
+      pairwise key-encryption key using the algorithm specified by the
+      KeyWrapAlgorithm.
+
+3.1.2.  Actions of the Sending Agent
+
+   When using ephemeral-static ECDH with EnvelopedData, the sending
+   agent first obtains the recipient's EC public key and domain
+   parameters (e.g., from the recipient's certificate).  The sending
+   agent then performs one of the two ECDH variations mentioned above:
+
+   - If the value of keyEncryptionAlgorithm indicates the use of
+     'standard' Diffie-Hellman, then the sending agent performs the
+     'Elliptic Curve Diffie-Hellman Scheme' with the 'Elliptic Curve
+     Diffie-Hellman Primitive' in [SEC1].
+
+   - If the value of keyEncryptionAlgorithm indicates the use of 'co-
+     factor' Diffie-Hellman, then the sending agent performs the 'One-
+     Pass Diffie-Hellman scheme' (method C(1, 1, ECC CDH)) in
+     [SP800-56A].
+
+   In both of these cases, the sending agent uses the KDF defined in
+   Section 3.6.1 of [SEC1] with the hash algorithm identified by the
+   value of keyEncryptionAlgorithm.  As a result, the sending agent
+   obtains:
+
+   -  an ephemeral public key, which is represented as a value of the
+      type ECPoint (see Section 7.2), encapsulated in a bit string and
+      placed in the KeyAgreeRecipientInfo originator originatorKey
+      publicKey field, and
+
+   -  a shared secret bit string "K", which is used as the pairwise key-
+      encryption key for that recipient, as specified in [CMS].
+
+   In a single message, if there are multiple layers for a recipient,
+   then the ephemeral public key can be reused by the originator for
+   that recipient in each of the different layers.
+
+3.1.3.  Actions of the Receiving Agent
+
+   When using ephemeral-static ECDH with EnvelopedData, the receiving
+   agent determines the bit string "SharedInfo", which is the DER
+   encoding of ECC-CMS-SharedInfo (see Section 7.2), and the integer
+   "keydatalen" from the key size, in bits, of the KeyWrapAlgorithm.
+   The receiving agent retrieves the ephemeral EC public key from the
+   bit string KeyAgreeRecipientInfo originator, with a value of the type
+   ECPoint (see Section 7.2) encapsulated as a bit string, and if
+
+
+
+Turner & Brown                Informational                     [Page 7]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   present, originally supplied additional user key material from the
+   ukm field.  The receiving agent then performs one of the two ECDH
+   variations mentioned above:
+
+   - If the value of keyEncryptionAlgorithm indicates the use of
+     'standard' Diffie-Hellman, then the receiving agent performs the
+     'Elliptic Curve Diffie-Hellman Scheme' with the 'Elliptic Curve
+     Diffie-Hellman Primitive' in [SEC1].
+
+   - If the value of keyEncryptionAlgorithm indicates the use of 'co-
+     factor' Diffie-Hellman, then the receiving agent performs the 'One-
+     Pass Diffie-Hellman scheme' (method C(1, 1, ECC CDH)) in
+     [SP800-56A].
+
+   In both of these cases, the receiving agent uses the KDF defined in
+   Section 3.6.1 of [SEC1] with the hash algorithm identified by the
+   value of keyEncryptionAlgorithm.  As a result, the receiving agent
+   obtains a shared secret bit string "K", which is used as the pairwise
+   key-encryption key to unwrap the CEK.
+
+3.2.  EnvelopedData Using 1-Pass ECMQV
+
+   This section describes how to use the 1-Pass Elliptic Curve Menezes-
+   Qu-Vanstone (ECMQV) key agreement algorithm with EnvelopedData,
+   method C(1, 2, ECC MQV) from [SP800-56A].  Like the KEA algorithm
+   [CMS-KEA], 1-Pass ECMQV uses three key pairs: an ephemeral key pair,
+   a static key pair of the sending agent, and a static key pair of the
+   receiving agent.  Using an algorithm with the sender static key pair
+   allows for knowledge of the message creator; this means that
+   authentication can, in some circumstances, be obtained for
+   AuthEnvelopedData and AuthenticatedData.  This means that 1-Pass
+   ECMQV can be a common algorithm for EnvelopedData, AuthenticatedData,
+   and AuthEnvelopedData, while ECDH can only be used in EnvelopedData.
+
+   If an implementation uses 1-Pass ECMQV with CMS EnvelopedData, then
+   the following techniques and formats MUST be used.
+
+   The fields of EnvelopedData are as in [CMS]; as 1-Pass ECMQV is a key
+   agreement algorithm, the RecipientInfo kari choice is used.  When
+   using 1-Pass ECMQV, the EnvelopedData originatorInfo field MAY
+   include the certificate(s) for the EC public key(s) used in the
+   formation of the pairwise key.  ECC certificates are discussed in
+   Section 5.
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                     [Page 8]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+3.2.1.  Fields of KeyAgreeRecipientInfo
+
+   When using 1-Pass ECMQV with EnvelopedData, the fields of
+   KeyAgreeRecipientInfo are as follows:
+
+   -  version MUST be 3.
+
+   -  originator identifies the static EC public key of the sender.  It
+      SHOULD be one of the alternatives, issuerAndSerialNumber or
+      subjectKeyIdentifier, and point to one of the sending agent's
+      certificates.
+
+   -  ukm MUST be present.  The ukm field is an octet string that MUST
+      contain the DER encoding of the type MQVuserKeyingMaterial (see
+      Section 7.2).  The MQVuserKeyingMaterial ephemeralPublicKey
+      algorithm field MUST contain the id-ecPublicKey object identifier
+      (see Section 7.1.2).  The parameters associated with id-
+      ecPublicKey MUST be absent, ECParameters, or NULL.  The parameters
+      associated with id-ecPublicKey SHOULD be absent or ECParameters,
+      as NULL is allowed to support legacy implementations.  The
+      previous version of this document required NULL to be present.  If
+      the parameters are ECParameters, then they MUST be namedCurve.
+      The MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST
+      contain the DER encoding of the ASN.1 type ECPoint (see Section
+      7.2) representing the sending agent's ephemeral EC public key.
+      The MQVuserKeyingMaterial addedukm field, if present, contains
+      additional user keying material from the sending agent.
+
+   -  keyEncryptionAlgorithm MUST contain the object identifier of the
+      key-encryption algorithm, which in this case is a key agreement
+      algorithm (see Section 7.1.4).  The parameters field contains
+      KeyWrapAlgorithm.  The KeyWrapAlgorithm indicates the symmetric
+      encryption algorithm used to encrypt the CEK with the KEK
+      generated using the 1-Pass ECMQV algorithm and any associated
+      parameters (see Section 7.1.5).  Algorithm requirements are found
+      in Section 8.
+
+   -  recipientEncryptedKeys contains an identifier and an encrypted key
+      for each recipient.  The RecipientEncryptedKey
+      KeyAgreeRecipientIdentifier MUST contain either the
+      issuerAndSerialNumber identifying the recipient's certificate or
+      the RecipientKeyIdentifier containing the subject key identifier
+      from the recipient's certificate.  In both cases, the recipient's
+      certificate contains the recipient's static ECMQV public key.
+      RecipientEncryptedKey EncryptedKey MUST contain the content-
+      encryption key encrypted with the 1-Pass ECMQV-generated pairwise
+      key-encryption key using the algorithm specified by the
+      KeyWrapAlgorithm.
+
+
+
+Turner & Brown                Informational                     [Page 9]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+3.2.2.  Actions of the Sending Agent
+
+   When using 1-Pass ECMQV with EnvelopedData, the sending agent first
+   obtains the recipient's EC public key and domain parameters (e.g.,
+   from the recipient's certificate), and checks that the domain
+   parameters are the same as the sender's domain parameters.  The
+   sending agent then determines an integer "keydatalen", which is the
+   KeyWrapAlgorithm symmetric key size in bits, and also a bit string
+   "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see
+   Section 7.2).  The sending agent then performs the key deployment and
+   key agreement operations of the Elliptic Curve MQV Scheme specified
+   in [SP800-56A], but uses the KDF defined in Section 3.6.1 of [SEC1].
+   As a result, the sending agent obtains:
+
+   - an ephemeral public key, which is represented as a value of type
+     ECPoint (see Section 7.2), encapsulated in a bit string, placed in
+     an MQVuserKeyingMaterial ephemeralPublicKey publicKey field (see
+     Section 7.2), and
+
+   - a shared secret bit string "K", which is used as the pairwise key-
+     encryption key for that recipient, as specified in [CMS].
+
+   In a single message, if there are multiple layers for a recipient,
+   then the ephemeral public key can be reused by the originator for
+   that recipient in each of the different layers.
+
+3.2.3.  Actions of the Receiving Agent
+
+   When using 1-Pass ECMQV with EnvelopedData, the receiving agent
+   determines the bit string "SharedInfo", which is the DER encoding of
+   ECC-CMS-SharedInfo (see Section 7.2), and the integer "keydatalen"
+   from the key size, in bits, of the KeyWrapAlgorithm.  The receiving
+   agent then retrieves the static and ephemeral EC public keys of the
+   originator, from the originator and ukm fields as described in
+   Section 3.2.1, and its static EC public key identified in the rid
+   field and checks that the originator's domain parameters are the same
+   as the recipient's domain parameters.  The receiving agent then
+   performs the key agreement operation of the Elliptic Curve MQV Scheme
+   [SP800-56A], but uses the KDF defined in Section 3.6.1 of [SEC1].  As
+   a result, the receiving agent obtains a shared secret bit string "K",
+   which is used as the pairwise key-encryption key to unwrap the CEK.
+
+
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 10]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+4.  AuthenticatedData and AuthEnvelopedData Using ECC
+
+   This section describes how to use ECC algorithms with the CMS
+   AuthenticatedData format.  AuthenticatedData lacks non-repudiation,
+   and so in some instances is preferable to SignedData.  (For example,
+   the sending agent might not want the message to be authenticated when
+   forwarded.)
+
+   This section also describes how to use ECC algorithms with the CMS
+   AuthEnvelopedData format [CMS-AUTHENV].  AuthEnvelopedData supports
+   authentication and encryption, and in some instances is preferable to
+   signing and then encrypting data.
+
+   For both AuthenticatedData and AuthEnvelopedData, data origin
+   authentication with 1-Pass ECMQV can only be provided when there is
+   one and only one recipient.  When there are multiple recipients, an
+   attack is possible where one recipient modifies the content without
+   other recipients noticing [BON].  A sending agent who is concerned
+   with such an attack SHOULD use a separate AuthenticatedData or
+   AuthEnvelopedData for each recipient.
+
+   Using an algorithm with the sender static key pair allows for
+   knowledge of the message creator; this means that authentication can,
+   in some circumstances, be obtained for AuthEnvelopedData and
+   AuthenticatedData.  This means that 1-Pass ECMQV can be a common
+   algorithm for EnvelopedData, AuthenticatedData, and AuthEnvelopedData
+   while ECDH can only be used in EnvelopedData.
+
+4.1.  AuthenticatedData Using 1-Pass ECMQV
+
+   This section describes how to use the 1-Pass ECMQV key agreement
+   algorithm with AuthenticatedData.  ECMQV is method C(1, 2, ECC MQV)
+   from [SP800-56A].
+
+   When using ECMQV with AuthenticatedData, the fields of
+   AuthenticatedData are as in [CMS], but with the following
+   restrictions:
+
+   - macAlgorithm MUST contain the algorithm identifier of the message
+     authentication code (MAC) algorithm (see Section 7.1.7), which MUST
+     be one of the following: hmac-SHA1, id-hmacWITHSHA224, id-
+     hmacWITHSHA256, id-hmacWITHSHA384, or id-hmacWITHSHA512.
+
+   - digestAlgorithm MUST contain the algorithm identifier of the hash
+     algorithm (see Section 7.1.1), which MUST be one of the following:
+     id-sha1, id-sha224, id-sha256, id-sha384, or id-sha512.
+
+
+
+
+
+Turner & Brown                Informational                    [Page 11]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   As 1-Pass ECMQV is a key agreement algorithm, the RecipientInfo kari
+   choice is used in the AuthenticatedData.  When using 1-Pass ECMQV,
+   the AuthenticatedData originatorInfo field MAY include the
+   certificate(s) for the EC public key(s) used in the formation of the
+   pairwise key.  ECC certificates are discussed in Section 5.
+
+4.1.1.  Fields of the KeyAgreeRecipientInfo
+
+   The AuthenticatedData KeyAgreeRecipientInfo fields are used in the
+   same manner as the fields for the corresponding EnvelopedData
+   KeyAgreeRecipientInfo fields of Section 3.2.1 of this document.
+
+4.1.2.  Actions of the Sending Agent
+
+   The sending agent uses the same actions as for EnvelopedData with
+   1-Pass ECMQV, as specified in Section 3.2.2 of this document.
+
+   In a single message, if there are multiple layers for a recipient,
+   then the ephemeral public key can be reused by the originator for
+   that recipient in each of the different layers.
+
+4.1.3.  Actions of the Receiving Agent
+
+   The receiving agent uses the same actions as for EnvelopedData with
+   1-Pass ECMQV, as specified in Section 3.2.3 of this document.
+
+4.2.  AuthEnvelopedData Using 1-Pass ECMQV
+
+   This section describes how to use the 1-Pass ECMQV key agreement
+   algorithm with AuthEnvelopedData.  ECMQV is method C(1, 2, ECC MQV)
+   from [SP800-56A].
+
+   When using ECMQV with AuthEnvelopedData, the fields of
+   AuthEnvelopedData are as in [CMS-AUTHENV].
+
+   As 1-Pass ECMQV is a key agreement algorithm, the RecipientInfo kari
+   choice is used.  When using 1-Pass ECMQV, the AuthEnvelopedData
+   originatorInfo field MAY include the certificate(s) for the EC public
+   key used in the formation of the pairwise key.  ECC certificates are
+   discussed in Section 5.
+
+4.2.1.  Fields of the KeyAgreeRecipientInfo
+
+   The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the
+   same manner as the fields for the corresponding EnvelopedData
+   KeyAgreeRecipientInfo fields of Section 3.2.1 of this document.
+
+
+
+
+
+Turner & Brown                Informational                    [Page 12]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+4.2.2.  Actions of the Sending Agent
+
+   The sending agent uses the same actions as for EnvelopedData with
+   1-Pass ECMQV, as specified in Section 3.2.2 of this document.
+
+   In a single message, if there are multiple layers for a recipient,
+   then the ephemeral public key can be reused by the originator for
+   that recipient in each of the different layers.
+
+4.2.3.  Actions of the Receiving Agent
+
+   The receiving agent uses the same actions as for EnvelopedData with
+   1-Pass ECMQV, as specified in Section 3.2.3 of this document.
+
+5.  Certificates Using ECC
+
+   Internet X.509 certificates [PKI] can be used in conjunction with
+   this specification to distribute agents' public keys.  The use of ECC
+   algorithms and keys within X.509 certificates is specified in
+   [PKI-ALG].
+
+6.  SMIMECapabilities Attribute and ECC
+
+   A sending agent MAY announce to receiving agents that it supports one
+   or more of the ECC algorithms specified in this document by using the
+   SMIMECapabilities signed attribute [MSG] in either a signed message
+   or a certificate [CERTCAP].
+
+   The SMIMECapabilities attribute value indicates support for one of
+   the ECDSA signature algorithms in a SEQUENCE with the capabilityID
+   field containing the object identifier ecdsa-with-SHA1 with NULL
+   parameters and ecdsa-with-SHA* (where * is 224, 256, 384, or 512)
+   with absent parameters.  The DER encodings are:
+
+      ecdsa-with-SHA1:   30 0b 06 07 2a 86 48 ce 3d 04 01 05 00
+
+      ecdsa-with-SHA224: 30 0a 06 08 2a 86 48 ce 3d 04 03 01
+
+      ecdsa-with-SHA256: 30 0a 06 08 2a 86 48 ce 3d 04 03 02
+
+      ecdsa-with-SHA384: 30 0a 06 08 2a 86 48 ce 3d 04 03 03
+
+      ecdsa-with-SHA512: 30 0a 06 08 2a 86 48 ce 3d 04 03 04
+
+   NOTE: The SMIMECapabilities attribute indicates that parameters for
+   ECDSA with SHA-1 are NULL; however, the parameters are absent when
+   used to generate a digital signature.
+
+
+
+
+Turner & Brown                Informational                    [Page 13]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   The SMIMECapabilities attribute value indicates support for
+
+      a)  the standard ECDH key agreement algorithm,
+      b)  the cofactor ECDH key agreement algorithm, or
+      c)  the 1-Pass ECMQV key agreement algorithm and
+
+   is a SEQUENCE with the capabilityID field containing the object
+   identifier
+
+      a)  dhSinglePass-stdDH-sha*kdf-scheme,
+      b)  dhSinglePass-cofactorDH-sha*kdf-scheme, or
+      c)  mqvSinglePass-sha*kdf-scheme
+
+   respectively (where * is 1, 224, 256, 384, or 512) with the
+   parameters present.  The parameters indicate the supported key-
+   encryption algorithm with the KeyWrapAlgorithm algorithm identifier.
+
+   The DER encodings that indicate capabilities are as follows (KA is
+   key agreement, KDF is key derivation function, and Wrap is key wrap
+   algorithm):
+
+      KA=ECDH standard KDF=SHA-1 Wrap=Triple-DES
+
+        30 1c 06 09 2b 81 05 10 86 48 3f 00 02 30 0f 06 0b 2a 86 48 86
+        f7 0d 01 09 10 03 06 05 00
+
+      KA=ECDH standard KDF=SHA-224 Wrap=Triple-DES
+
+        30 17 06 06 2b 81 04 01 0B 00 30 0d 06 0b 2a 86 48 86 f7 0d 01
+        09 10 03 06
+
+      KA=ECDH standard KDF=SHA-256 Wrap=Triple-DES
+
+        30 17 06 06 2b 81 04 01 0B 01 30 0d 06 0b 2a 86 48 86 f7 0d 01
+        09 10 03 06
+
+      KA=ECDH standard KDF=SHA-384 Wrap=Triple-DES
+
+        30 17 06 06 2b 81 04 01 0B 02 30 0d 06 0b 2a 86 48 86 f7 0d 01
+        09 10 03 06
+
+      KA=ECDH standard KDF=SHA-512 Wrap=Triple-DES
+
+        30 17 06 06 2b 81 04 01 0B 03 30 0d 06 0b 2a 86 48 86 f7 0d 01
+        09 10 03 06
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 14]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+      KA=ECDH standard KDF=SHA-1 Wrap=AES-128
+
+        30 18 06 09 2b 81 05 10 86 48 3f 00 02 30 0b 06 09 60 86 48 01
+        65 03 04 01 05
+
+      KA=ECDH standard KDF=SHA-224 Wrap=AES-128
+
+        30 15 06 06 2b 81 04 01 0B 00 30 0b 06 09 60 86 48 01 65 03 04
+        01 05
+
+      KA=ECDH standard KDF=SHA-256 Wrap=AES-128
+
+        30 15 06 06 2b 81 04 01 0B 01 30 0b 06 09 60 86 48 01 65 03 04
+        01 05
+
+      KA=ECDH standard KDF=SHA-384 Wrap=AES-128
+
+        30 15 06 06 2b 81 04 01 0B 02 30 0b 06 09 60 86 48 01 65 03 04
+        01 05
+
+      KA=ECDH standard KDF=SHA-512 Wrap=AES-128
+
+        30 15 06 06 2b 81 04 01 0B 03 30 0b 06 09 60 86 48 01 65 03 04
+        01 05
+
+      KA=ECDH standard KDF=SHA-1 Wrap=AES-192
+
+        30 18 06 09 2b 81 05 10 86 48 3f 00 02 30 0b 06 09 60 86 48 01
+        65 03 04 01 19
+
+      KA=ECDH standard KDF=SHA-224 Wrap=AES-192
+
+        30 15 06 06 2b 81 04 01 0B 00 30 0b 06 09 60 86 48 01 65 03 04
+        01 19
+
+      KA=ECDH standard KDF=SHA-256 Wrap=AES-192
+
+        30 15 06 06 2b 81 04 01 0B 01 30 0b 06 09 60 86 48 01 65 03 04
+        01 19
+
+      KA=ECDH standard KDF=SHA-384 Wrap=AES-192
+
+        30 15 06 06 2b 81 04 01 0B 02 30 0b 06 09 60 86 48 01 65 03 04
+        01 19
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 15]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+      KA=ECDH standard KDF=SHA-512 Wrap=AES-192
+
+        30 15 06 06 2b 81 04 01 0B 03 30 0b 06 09 60 86 48 01 65 03 04
+        01 19
+
+      KA=ECDH standard KDF=SHA-1 Wrap=AES-256
+
+        30 18 06 09 2b 81 05 10 86 48 3f 00 02 30 0b 06 09 60 86 48 01
+        65 03 04 01 2D
+
+      KA=ECDH standard KDF=SHA-224 Wrap=AES-256
+
+        30 15 06 06 2b 81 04 01 0B 00 30 0b 06 09 60 86 48 01 65 03 04
+        01 2D
+
+      KA=ECDH standard KDF=SHA-256 Wrap=AES-256
+
+        30 15 06 06 2b 81 04 01 0B 01 30 0b 06 09 60 86 48 01 65 03 04
+        01 2D
+
+      KA=ECDH standard KDF=SHA-384 Wrap=AES-256
+
+        30 15 06 06 2b 81 04 01 0B 02 30 0b 06 09 60 86 48 01 65 03 04
+        01 2D 05 00
+
+      KA=ECDH standard KDF=SHA-512 Wrap=AES-256
+
+        30 15 06 06 2b 81 04 01 0B 03 30 0b 06 09 60 86 48 01 65 03 04
+        01 2D
+
+      KA=ECDH cofactor KDF=SHA-1 Wrap=Triple-DES
+
+        30 1c 06 09 2b 81 05 10 86 48 3f 00 03 30 0f 06 0b 2a 86 48 86
+        f7 0d 01 09 10 03 06 05 00
+
+      KA=ECDH cofactor KDF=SHA-224 Wrap=Triple-DES
+
+        30 17 06 06 2b 81 04 01 0E 00 30 0d 06 0b 2a 86 48 86 f7 0d 01
+        09 10 03 06
+
+      KA=ECDH cofactor KDF=SHA-256 Wrap=Triple-DES
+
+        30 17 06 06 2b 81 04 01 0E 01 30 0d 06 0b 2a 86 48 86 f7 0d 01
+        09 10 03 06
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 16]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+      KA=ECDH cofactor KDF=SHA-384 Wrap=Triple-DES
+
+        30 17 06 06 2b 81 04 01 0E 02 30 0d 06 0b 2a 86 48 86 f7 0d 01
+        09 10 03 06
+
+      KA=ECDH cofactor KDF=SHA-512 Wrap=Triple-DES
+
+        30 17 06 06 2b 81 04 01 0E 03 30 0d 06 0b 2a 86 48 86 f7 0d 01
+        09 10 03 06
+
+      KA=ECDH cofactor KDF=SHA-1 Wrap=AES-128
+
+        30 18 06 09 2b 81 05 10 86 48 3f 00 03 30 0b 06 09 60 86 48 01
+        65 03 04 01 05
+
+      KA=ECDH cofactor KDF=SHA-224 Wrap=AES-128
+
+        30 15 06 06 2b 81 04 01 0E 00 30 0b 06 09 60 86 48 01 65 03 04
+        01 05
+
+      KA=ECDH cofactor KDF=SHA-256 Wrap=AES-128
+
+        30 15 06 06 2b 81 04 01 0E 01 30 0b 06 09 60 86 48 01 65 03 04
+        01 05
+
+      KA=ECDH cofactor KDF=SHA-384 Wrap=AES-128
+
+        30 15 06 06 2b 81 04 01 0E 02 30 0b 06 09 60 86 48 01 65 03 04
+        01 05
+
+      KA=ECDH cofactor KDF=SHA-512 Wrap=AES-128
+
+        30 17 06 06 2b 81 04 01 0E 03 30 0b 06 09 60 86 48 01 65 03 04
+        01 05
+
+      KA=ECDH cofactor KDF=SHA-1 Wrap=AES-192
+
+        30 18 06 09 2b 81 05 10 86 48 3f 00 03 30 0b 06 09 60 86 48 01
+        65 03 04 01 19
+
+      KA=ECDH cofactor KDF=SHA-224 Wrap=AES-192
+
+        30 15 06 06 2b 81 04 01 0E 00 30 0b 06 09 60 86 48 01 65 03 04
+        01 19
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 17]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+      KA=ECDH cofactor KDF=SHA-256 Wrap=AES-192
+
+        30 15 06 06 2b 81 04 01 0E 01 30 0b 06 09 60 86 48 01 65 03 04
+        01 19
+
+      KA=ECDH cofactor KDF=SHA-384 Wrap=AES-192
+
+        30 15 06 06 2b 81 04 01 0E 02 30 0b 06 09 60 86 48 01 65 03 04
+        01 19
+
+      KA=ECDH cofactor KDF=SHA-512 Wrap=AES-192
+
+        30 15 06 06 2b 81 04 01 0E 03 30 0b 06 09 60 86 48 01 65 03 04
+        01 19
+
+      KA=ECDH cofactor KDF=SHA-1 Wrap=AES-256
+
+        30 15 06 09 2b 81 05 10 86 48 3f 00 03 30 0b 06 09 60 86 48 01
+        65 03 04 01 2D
+
+      KA=ECDH cofactor KDF=SHA-224 Wrap=AES-256
+
+        30 15 06 06 2b 81 04 01 0E 00 30 0b 06 09 60 86 48 01 65 03 04
+        01 2D
+
+      KA=ECDH cofactor KDF=SHA-256 Wrap=AES-256
+
+        30 15 06 06 2b 81 04 01 0E 01 30 0b 06 09 60 86 48 01 65 03 04
+        01 2D
+
+      KA=ECDH cofactor KDF=SHA-384 Wrap=AES-256
+
+        30 15 06 06 2b 81 04 01 0E 02 30 0b 06 09 60 86 48 01 65 03 04
+        01 2D
+
+      KA=ECDH cofactor KDF=SHA-512 Wrap=AES-256
+
+        30 15 06 06 2b 81 04 01 0E 03 30 0b 06 09 60 86 48 01 65 03 04
+        01 2D
+
+      KA=ECMQV 1-Pass KDF=SHA-1 Wrap=Triple-DES
+
+        30 1c 06 09 2b 81 05 10 86 48 3f 00 10 30 0f 06 0b 2a 86 48 86
+        f7 0d 01 09 10 03 06 05 00
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 18]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+      KA=ECMQV 1-Pass KDF=SHA-224 Wrap=Triple-DES
+
+        30 17 06 06 2b 81 04 01 0F 00 30 0d 06 0b 2a 86 48 86 f7 0d 01
+        09 10 03 06
+
+      KA=ECMQV 1-Pass KDF=SHA-256 Wrap=Triple-DES
+
+        30 17 06 06 2b 81 04 01 0F 01 30 0d 06 0b 2a 86 48 86 f7 0d 01
+        09 10 03 06
+
+      KA=ECMQV 1-Pass KDF=SHA-384 Wrap=Triple-DES
+
+        30 17 06 06 2b 81 04 01 0F 02 30 0d 06 0b 2a 86 48 86 f7 0d 01
+        09 10 03 06
+
+      KA=ECMQV 1-Pass KDF=SHA-512 Wrap=Triple-DES
+
+        30 17 06 06 2b 81 04 01 0F 03 30 0d 06 0b 2a 86 48 86 f7 0d 01
+        09 10 03 06
+
+      KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-128
+
+        30 18 06 09 2b 81 05 10 86 48 3f 00 10 30 0b 06 09 60 86 48 01
+        65 03 04 01 05
+
+      KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-128
+
+        30 15 06 06 2b 81 04 01 0F 00 30 0b 06 09 60 86 48 01 65 03 04
+        01 05
+
+      KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-128
+
+        30 15 06 06 2b 81 04 01 0F 01 30 0b 06 09 60 86 48 01 65 03 04
+        01 05
+
+      KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-128
+
+        30 15 06 06 2b 81 04 01 0F 02 30 0b 06 09 60 86 48 01 65 03 04
+        01 05
+
+      KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-128
+
+        30 15 06 06 2b 81 04 01 0F 03 30 0b 06 09 60 86 48 01 65 03 04
+        01 05
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 19]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+      KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-192
+
+        30 18 06 09 2b 81 05 10 86 48 3f 00 10 30 0b 06 09 60 86 48 01
+        65 03 04 01 19
+
+      KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-192
+
+        30 15 06 06 2b 81 04 01 0F 00 30 0b 06 09 60 86 48 01 65 03 04
+        01 19
+
+      KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-192
+
+        30 15 06 06 2b 81 04 01 0F 01 30 0b 06 09 60 86 48 01 65 03 04
+        01 19
+
+      KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-192
+
+        30 15 06 06 2b 81 04 01 0F 02 30 0b 06 09 60 86 48 01 65 03 04
+        01 19
+
+      KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-192
+
+        30 15 06 06 2b 81 04 01 0F 03 30 0b 06 09 60 86 48 01 65 03 04
+        01 19
+
+      KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-256
+
+        30 18 06 09 2b 81 05 10 86 48 3f 00 10 30 0b 06 09 60 86 48 01
+        65 03 04 01 2D
+
+      KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-256
+
+        30 15 06 06 2b 81 04 01 0F 00 30 0b 06 09 60 86 48 01 65 03 04
+        01 2D
+
+      KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-256
+
+        30 15 06 06 2b 81 04 01 0F 01 30 0b 06 09 60 86 48 01 65 03 04
+        01 2D
+
+      KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-256
+
+        30 15 06 06 2b 81 04 01 0F 02 30 0b 06 09 60 86 48 01 65 03 04
+        01 2D
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 20]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+      KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-256
+
+        30 15 06 06 2b 81 04 01 0F 03 30 0b 06 09 60 86 48 01 65 03 04
+        01 2D
+
+   NOTE: The S/MIME Capabilities for the supported AES content-
+   encryption key sizes are defined in [CMS-AES].
+
+   NOTE: The S/MIME Capabilities for the supported MAC algorithms are
+   defined in [CMS-ASN].
+
+7.  ASN.1 Syntax
+
+   The ASN.1 syntax [X.680], [X.681], [X.682], [X.683] used in this
+   document is gathered in this section for reference purposes.
+
+7.1.  Algorithm Identifiers
+
+   This section provides the object identifiers for the algorithms used
+   in this document along with any associated parameters.
+
+7.1.1.  Digest Algorithms
+
+   Digest algorithm object identifiers are used in the SignedData
+   digestAlgorithms and digestAlgorithm fields and the AuthenticatedData
+   digestAlgorithm field.  The digest algorithms used in this document
+   are SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512.  The object
+   identifiers and parameters associated with these algorithms are found
+   in [CMS-ALG] and [CMS-SHA2].
+
+7.1.2.  Originator Public Key
+
+   The KeyAgreeRecipientInfo originator field uses the following object
+   identifier to indicate an elliptic curve public key:
+
+      id-ecPublicKey OBJECT IDENTIFIER ::= {
+        ansi-x9-62 keyType(2) 1 }
+
+   where
+
+      ansi-x9-62 OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) 10045 }
+
+   When the object identifier id-ecPublicKey is used here with an
+   algorithm identifier, the associated parameters MUST be either absent
+   or ECParameters.  Implementations MUST accept id-ecPublicKey with
+   absent and ECParameters parameters.  If ECParameters is present, its
+
+
+
+
+Turner & Brown                Informational                    [Page 21]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   value MUST match the recipient's ECParameters.  Implementations
+   SHOULD generate absent parameters for the id-ecPublicKey object
+   identifier in the KeyAgreeRecipientInfo originator field.
+
+   [CMS-ECC] indicated the parameters were NULL.  Support for this
+   legacy form is OPTIONAL.
+
+7.1.3.  Signature Algorithms
+
+   Signature algorithm identifiers are used in the SignedData
+   signatureAlgorithm and signature fields.  The signature algorithms
+   used in this document are ECDSA with SHA-1, ECDSA with SHA-224, ECDSA
+   with SHA-256, ECDSA with SHA-384, and ECDSA with SHA-512.  The object
+   identifiers and parameters associated with these algorithms are found
+   in [PKI-ALG].
+
+   [CMS-ECC] indicated the parameters were NULL.  Support for this
+   legacy form is OPTIONAL.
+
+7.1.4.  Key Agreement Algorithms
+
+   Key agreement algorithms are used in EnvelopedData,
+   AuthenticatedData, and AuthEnvelopedData in the KeyAgreeRecipientInfo
+   keyEncryptionAlgorithm field.  The following object identifiers
+   indicate the key agreement algorithms used in this document
+   [SP800-56A], [SEC1]:
+
+      dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
+        x9-63-scheme 2 }
+
+      dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
+        secg-scheme 11 0 }
+
+      dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
+        secg-scheme 11 1 }
+
+      dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
+        secg-scheme 11 2 }
+
+      dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
+        secg-scheme 11 3 }
+
+      dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
+        x9-63-scheme 3 }
+
+      dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
+        secg-scheme 14 0 }
+
+
+
+
+Turner & Brown                Informational                    [Page 22]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+      dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
+        secg-scheme 14 1 }
+
+      dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
+        secg-scheme 14 2 }
+
+      dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
+        secg-scheme 14 3 }
+
+      mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= {
+        x9-63-scheme 16 }
+
+      mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= {
+        secg-scheme 15 0 }
+
+      mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= {
+        secg-scheme 15 1 }
+
+      mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= {
+        secg-scheme 15 2 }
+
+      mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= {
+        secg-scheme 15 3 }
+
+   where
+
+      x9-63-scheme OBJECT IDENTIFIER ::= {
+        iso(1) identified-organization(3) tc68(133) country(16)
+        x9(840) x9-63(63) schemes(0) }
+
+   and
+
+      secg-scheme OBJECT IDENTIFIER ::= {
+        iso(1) identified-organization(3) certicom(132) schemes(1) }
+
+   When the object identifiers are used here within an algorithm
+   identifier, the associated parameters field contains KeyWrapAlgorithm
+   to indicate the key wrap algorithm and any associated parameters.
+
+7.1.5.  Key Wrap Algorithms
+
+   Key wrap algorithms are used as part of the parameters in the key
+   agreement algorithm.  The key wrap algorithms used in this document
+   are Triple-DES, AES-128, AES-192, and AES-256.  The object
+   identifiers and parameters for these algorithms are found in
+   [CMS-ALG] and [CMS-AES].
+
+
+
+
+
+Turner & Brown                Informational                    [Page 23]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+7.1.6.  Content Encryption Algorithms
+
+   Content encryption algorithms are used in EnvelopedData and
+   AuthEnvelopedData in the EncryptedContentInfo
+   contentEncryptionAlgorithm field.  The content encryption algorithms
+   used with EnvelopedData in this document are 3-Key Triple DES in CBC
+   mode, AES-128 in CBC mode, AES-192 in CBC mode, and AES-256 in CBC
+   mode.  The object identifiers and parameters associated with these
+   algorithms are found in [CMS-ALG] and [CMS-AES].  The content
+   encryption algorithms used with AuthEnvelopedData in this document
+   are AES-128 in CCM mode, AES-192 in CCM mode, AES-256 in CCM mode,
+   AES-128 in GCM mode, AES-192 in GCM mode, and AES-256 in GCM mode.
+   The object identifiers and parameters associated with these
+   algorithms are found in [CMS-AESCG].
+
+7.1.7.  Message Authentication Code Algorithms
+
+   Message authentication code algorithms are used in AuthenticatedData
+   in the macAlgorithm field.  The message authentication code
+   algorithms used in this document are HMAC with SHA-1, HMAC with
+   SHA-224, HMAC with SHA-256, HMAC with SHA-384, and HMAC with SHA-512.
+   The object identifiers and parameters associated with these
+   algorithms are found in [CMS-ALG] and [HMAC-SHA2].
+
+   NOTE: [HMAC-SHA2] defines the object identifiers for HMAC with
+   SHA-224, HMAC with SHA-256, HMAC with SHA-384, and HMAC with SHA-512,
+   but there is no ASN.1 module from which to import these object
+   identifiers.  Therefore, the object identifiers for these algorithms
+   are included in the ASN.1 modules defined in Appendix A.
+
+7.1.8.  Key Derivation Algorithm
+
+   The KDF used in this document is as specified in Section 3.6.1 of
+   [SEC1].  The hash algorithm is identified in the key agreement
+   algorithm.  For example, dhSinglePass-stdDH-sha256kdf-scheme uses the
+   KDF from [SEC1] but uses SHA-256 instead of SHA-1.
+
+7.2.  Other Syntax
+
+   The following additional syntax is used here.
+
+   When using ECDSA with SignedData, ECDSA signatures are encoded using
+   the type:
+
+      ECDSA-Sig-Value ::= SEQUENCE {
+        r INTEGER,
+        s INTEGER }
+
+
+
+
+Turner & Brown                Informational                    [Page 24]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   ECDSA-Sig-Value is specified in [PKI-ALG].  Within CMS, ECDSA-Sig-
+   Value is DER-encoded and placed within a signature field of
+   SignedData.
+
+   When using ECDH and ECMQV with EnvelopedData, AuthenticatedData, and
+   AuthEnvelopedData, ephemeral and static public keys are encoded using
+   the type ECPoint.  Implementations MUST support uncompressed keys,
+   MAY support compressed keys, and MUST NOT support hybrid keys.
+
+      ECPoint ::= OCTET STRING
+
+   When using ECMQV with EnvelopedData, AuthenticatedData, and
+   AuthEnvelopedData, the sending agent's ephemeral public key and
+   additional keying material are encoded using the type:
+
+      MQVuserKeyingMaterial ::= SEQUENCE {
+        ephemeralPublicKey      OriginatorPublicKey,
+        addedukm            [0] EXPLICIT UserKeyingMaterial OPTIONAL  }
+
+   The ECPoint syntax is used to represent the ephemeral public key and
+   is placed in the ephemeralPublicKey publicKey field.  The additional
+   user keying material is placed in the addedukm field.  Then the
+   MQVuserKeyingMaterial value is DER-encoded and placed within the ukm
+   field of EnvelopedData, AuthenticatedData, or AuthEnvelopedData.
+
+   When using ECDH or ECMQV with EnvelopedData, AuthenticatedData, or
+   AuthEnvelopedData, the key-encryption keys are derived by using the
+   type:
+
+      ECC-CMS-SharedInfo ::= SEQUENCE {
+        keyInfo         AlgorithmIdentifier,
+        entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
+        suppPubInfo [2] EXPLICIT OCTET STRING  }
+
+   The fields of ECC-CMS-SharedInfo are as follows:
+
+      keyInfo contains the object identifier of the key-encryption
+      algorithm (used to wrap the CEK) and associated parameters.  In
+      this specification, 3DES wrap has NULL parameters while the AES
+      wraps have absent parameters.
+
+      entityUInfo optionally contains additional keying material
+      supplied by the sending agent.  When used with ECDH and CMS, the
+      entityUInfo field contains the octet string ukm.  When used with
+      ECMQV and CMS, the entityUInfo contains the octet string addedukm
+      (encoded in MQVuserKeyingMaterial).
+
+
+
+
+
+Turner & Brown                Informational                    [Page 25]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+      suppPubInfo contains the length of the generated KEK, in bits,
+      represented as a 32-bit number, as in [CMS-DH] and [CMS-AES].
+      (For example, for AES-256 it would be 00 00 01 00.)
+
+   Within CMS, ECC-CMS-SharedInfo is DER-encoded and used as input to
+   the key derivation function, as specified in Section 3.6.1 of [SEC1].
+
+   NOTE: ECC-CMS-SharedInfo differs from the OtherInfo specified in
+   [CMS-DH].  Here, a counter value is not included in the keyInfo field
+   because the key derivation function specified in Section 3.6.1 of
+   [SEC1] ensures that sufficient keying data is provided.
+
+8.  Recommended Algorithms and Elliptic Curves
+
+   It is RECOMMENDED that implementations of this specification support
+   SignedData and EnvelopedData.  Support for AuthenticatedData and
+   AuthEnvelopedData is OPTIONAL.
+
+   In order to encourage interoperability, implementations SHOULD use
+   the elliptic curve domain parameters specified by [PKI-ALG].
+
+   Implementations that support SignedData with ECDSA:
+
+      - MUST support ECDSA with SHA-256; and
+
+      - MAY support ECDSA with SHA-1, ECDSA with SHA-224, ECDSA with
+        SHA-384, and ECDSA with SHA-512; other digital signature
+        algorithms MAY also be supported.
+
+   When using ECDSA, to promote interoperability it is RECOMMENDED that
+   the P-192, P-224, and P-256 curves be used with SHA-256; the P-384
+   curve be used with SHA-384; and the P-521 curve be used with SHA-512.
+
+   If EnvelopedData is supported, then ephemeral-static ECDH standard
+   primitive MUST be supported.  Support for ephemeral-static ECDH co-
+   factor is OPTIONAL, and support for 1-Pass ECMQV is also OPTIONAL.
+
+   Implementations that support EnvelopedData with the ephemeral-static
+   ECDH standard primitive:
+
+      - MUST support the dhSinglePass-stdDH-sha256kdf-scheme key
+        agreement algorithm, the id-aes128-wrap key wrap algorithm, and
+        the id-aes128-cbc content encryption algorithm; and
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 26]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+      - MAY support the dhSinglePass-stdDH-sha1kdf-scheme, dhSinglePass-
+        stdDH-sha224kdf-scheme, dhSinglePass-stdDH-sha384kdf-scheme, and
+        dhSinglePass-stdDH-sha512kdf-scheme key agreement algorithms;
+        the id-alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key
+        wrap algorithms; and the des-ede3-cbc, id-aes192-cbc, and id-
+        aes256-cbc content encryption algorithms; other algorithms MAY
+        also be supported.
+
+   Implementations that support EnvelopedData with the ephemeral-static
+   ECDH cofactor primitive:
+
+      - MUST support the dhSinglePass-cofactorDH-sha256kdf-scheme key
+        agreement algorithm, the id-aes128-wrap key wrap algorithm, and
+        the id-aes128-cbc content encryption algorithm; and
+
+      - MAY support the dhSinglePass-cofactorDH-sha1kdf-scheme,
+        dhSinglePass-cofactorDH-sha224kdf-scheme, dhSinglePass-
+        cofactorDH-sha384kdf-scheme, and dhSinglePass-cofactorDH-
+        sha512kdf-scheme key agreement; the id-alg-CMS3DESwrap, id-
+        aes192-wrap, and id-aes256-wrap key wrap algorithms; and the
+        des-ede3-cbc, id-aes192-cbc, and id-aes256-cbc content
+        encryption algorithms; other algorithms MAY also be supported.
+
+   Implementations that support EnvelopedData with 1-Pass ECMQV:
+
+      - MUST support the mqvSinglePass-sha256kdf-scheme key agreement
+        algorithm, the id-aes128-wrap key wrap algorithm, and the id-
+        aes128-cbc content encryption algorithm; and
+
+      - MAY support the mqvSinglePass-sha1kdf-scheme, mqvSinglePass-
+        sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, and
+        mqvSinglePass-sha512kdf-scheme key agreement algorithms; the id-
+        alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap
+        algorithms; and the des-ede3-cbc, id-aes192-cbc, and id-
+        aes256-cbc content encryption algorithms; other algorithms MAY
+        also be supported.
+
+   Implementations that support AuthenticatedData with 1-Pass ECMQV:
+
+      - MUST support the mqvSinglePass-sha256kdf-scheme key agreement,
+        the id-aes128-wrap key wrap, the id-sha256 message digest, and
+        id-hmacWithSHA256 message authentication code algorithms; and
+
+      - MAY support the mqvSinglePass-sha1kdf-scheme, mqvSinglePass-
+        sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, mqvSinglePass-
+        sha512kdf-scheme key agreement algorithms; the id-alg-
+        CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap
+        algorithms; the id-sha1, id-sha224, id-sha384, and id-sha512,
+
+
+
+Turner & Brown                Informational                    [Page 27]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+        message digest algorithms; and the hmac-SHA1, id-hmacWithSHA224,
+        id-hmacWithSHA384, and id-hmacWithSHA512 message authentication
+        code algorithms; other algorithms MAY also be supported.
+
+   Implementations that support AuthEnvelopedData with 1-Pass ECMQV:
+
+      - MUST support the mqvSinglePass-sha256kdf-scheme key agreement,
+        the id-aes128-wrap key wrap, and the id-aes128-ccm
+        authenticated-content encryption; and
+
+      - MAY support the mqvSinglePass-sha1kdf-scheme, mqvSinglePass-
+        sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, and
+        mqvSinglePass-sha512kdf-scheme key agreement algorithms; the id-
+        alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap
+        algorithms; and the id-aes192-ccm, id-aes256-ccm, id-aes128-gcm,
+        id-aes192-gcm, and id-aes256-ccm authenticated-content
+        encryption algorithms; other algorithms MAY also be supported.
+
+9.  Security Considerations
+
+   Cryptographic algorithms will be broken or weakened over time.
+   Implementers and users need to check that the cryptographic
+   algorithms listed in this document continue to provide the expected
+   level of security.  The IETF from time to time may issue documents
+   dealing with the current state of the art.
+
+   Cryptographic algorithms rely on random numbers.  See [RANDOM] for
+   guidance on generation of random numbers.
+
+   Receiving agents that validate signatures and sending agents that
+   encrypt messages need to be cautious of cryptographic processing
+   usage when validating signatures and encrypting messages using keys
+   larger than those mandated in this specification.  An attacker could
+   send keys and/or certificates with keys that would result in
+   excessive cryptographic processing, for example, keys larger than
+   those mandated in this specification, which could swamp the
+   processing element.  Agents that use such keys without first
+   validating the certificate to a trust anchor are advised to have some
+   sort of cryptographic resource management system to prevent such
+   attacks.
+
+   Using secret keys of an appropriate size is crucial to the security
+   of a Diffie-Hellman exchange.  For elliptic curve groups, the size of
+   the secret key must be equal to the size of n (the order of the group
+   generated by the point g).  Using larger secret keys provides
+   absolutely no additional security, and using smaller secret keys is
+   likely to result in dramatically less security.  (See [SP800-56A] for
+   more information on selecting secret keys.)
+
+
+
+Turner & Brown                Informational                    [Page 28]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   This specification is based on [CMS], [CMS-AES], [CMS-AESCG],
+   [CMS-ALG], [CMS-AUTHENV], [CMS-DH], [CMS-SHA2], [FIPS180-3],
+   [FIPS186-3], and [HMAC-SHA2], and the appropriate security
+   considerations of those documents apply.
+
+   In addition, implementers of AuthenticatedData and AuthEnvelopedData
+   should be aware of the concerns expressed in [BON] when using
+   AuthenticatedData and AuthEnvelopedData to send messages to more than
+   one recipient.  Also, users of MQV should be aware of the
+   vulnerability described in [K].
+
+   When implementing EnvelopedData, AuthenticatedData, and
+   AuthEnvelopedData, there are five algorithm-related choices that need
+   to be made:
+
+      1) What is the public key size?
+      2) What is the KDF?
+      3) What is the key wrap algorithm?
+      4) What is the content encryption algorithm?
+      5) What is the curve?
+
+   Consideration must be given to the strength of the security provided
+   by each of these choices.  Security algorithm strength is measured in
+   bits, where bits is measured in equivalence to a symmetric cipher
+   algorithm.  Thus, a strong symmetric cipher algorithm with a key of X
+   bits is said to provide X bits of security.  For other algorithms,
+   the key size is mapped to an equivalent symmetric cipher strength.
+   It is recommended that the bits of security provided by each are
+   roughly equivalent.  The following table provides comparable minimum
+   bits of security [SP800-57] for the ECDH/ECMQV key sizes, KDFs, key
+   wrapping algorithms, and content encryption algorithms.  It also
+   lists curves [PKI-ALG] for the key sizes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 29]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   Minimum  | ECDH or  | Key        | Key      | Content     | Curves
+   Bits of  | ECMQV    | Derivation | Wrap     | Encryption  |
+   Security | Key Size | Function   | Alg.     | Alg.        |
+   ---------+----------+------------+----------+-------------+----------
+   80       | 160-223  | SHA-1      | 3DES     | 3DES CBC    | sect163k1
+            |          | SHA-224    | AES-128  | AES-128 CBC | secp163r2
+            |          | SHA-256    | AES-192  | AES-192 CBC | secp192r1
+            |          | SHA-384    | AES-256  | AES-256 CBC |
+            |          | SHA-512    |          |             |
+   ---------+----------+------------+----------+-------------+---------
+   112      | 224-255  | SHA-1      | 3DES     | 3DES CBC    | secp224r1
+            |          | SHA-224    | AES-128  | AES-128 CBC | sect233k1
+            |          | SHA-256    | AES-192  | AES-192 CBC | sect233r1
+            |          | SHA-384    | AES-256  | AES-256 CBC |
+            |          | SHA-512    |          |             |
+   ---------+----------+------------+----------+-------------+---------
+   128      | 256-383  | SHA-1      | AES-128  | AES-128 CBC | secp256r1
+            |          | SHA-224    | AES-192  | AES-192 CBC | sect283k1
+            |          | SHA-256    | AES-256  | AES-256 CBC | sect283r1
+            |          | SHA-384    |          |             |
+            |          | SHA-512    |          |             |
+   ---------+----------+------------+----------+-------------+---------
+   192      | 384-511  | SHA-224    | AES-192  | AES-192 CBC | secp384r1
+            |          | SHA-256    | AES-256  | AES-256 CBC | sect409k1
+            |          | SHA-384    |          |             | sect409r1
+            |          | SHA-512    |          |             |
+   ---------+----------+------------+----------+-------------+---------
+   256      | 512+     | SHA-256    | AES-256  | AES-256 CBC | secp521r1
+            |          | SHA-384    |          |             | sect571k1
+            |          | SHA-512    |          |             | sect571r1
+   ---------+----------+------------+----------+-------------+---------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 30]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   To promote interoperability, the following choices are RECOMMENDED:
+
+   Minimum  | ECDH or  | Key        | Key      | Content     | Curve
+   Bits of  | ECMQV    | Derivation | Wrap     | Encryption  |
+   Security | Key Size | Function   | Alg.     | Alg.        |
+   ---------+----------+------------+----------+-------------+----------
+   80       | 192      | SHA-256    | 3DES     | 3DES CBC    | secp192r1
+   ---------+----------+------------+----------+-------------+----------
+   112      | 224      | SHA-256    | 3DES     | 3DES CBC    | secp224r1
+   ---------+----------+------------+----------+-------------+----------
+   128      | 256      | SHA-256    | AES-128  | AES-128 CBC | secp256r1
+   ---------+----------+------------+----------+-------------+----------
+   192      | 384      | SHA-384    | AES-256  | AES-256 CBC | secp384r1
+   ---------+----------+------------+----------+-------------+----------
+   256      | 512+     | SHA-512    | AES-256  | AES-256 CBC | secp521r1
+   ---------+----------+------------+----------+-------------+----------
+
+   When implementing SignedData, there are three algorithm-related
+   choices that need to be made:
+
+      1) What is the public key size?
+      2) What is the hash algorithm?
+      3) What is the curve?
+
+   Consideration must be given to the bits of security provided by each
+   of these choices.  Security is measured in bits, where a strong
+   symmetric cipher with a key of X bits is said to provide X bits of
+   security.  It is recommended that the bits of security provided by
+   each choice are roughly equivalent.  The following table provides
+   comparable minimum bits of security [SP800-57] for the ECDSA key
+   sizes and message digest algorithms.  It also lists curves [PKI-ALG]
+   for the key sizes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 31]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   Minimum  | ECDSA    | Message   | Curve
+   Bits of  | Key Size | Digest    |
+   Security |          | Algorithm |
+   ---------+----------+-----------+-----------
+   80       | 160-223  | SHA-1     | sect163k1
+            |          | SHA-224   | secp163r2
+            |          | SHA-256   | secp192r1
+            |          | SHA-384   |
+            |          | SHA-512   |
+   ---------+----------+-----------+-----------
+   112      | 224-255  | SHA-224   | secp224r1
+            |          | SHA-256   | sect233k1
+            |          | SHA-384   | sect233r1
+            |          | SHA-512   |
+   ---------+----------+-----------+-----------
+   128      | 256-383  | SHA-256   | secp256r1
+            |          | SHA-384   | sect283k1
+            |          | SHA-512   | sect283r1
+   ---------+----------+-----------+-----------
+   192      | 384-511  | SHA-384   | secp384r1
+            |          | SHA-512   | sect409k1
+            |          |           | sect409r1
+   ---------+----------+-----------+-----------
+   256      | 512+     | SHA-512   | secp521r1
+            |          |           | sect571k1
+            |          |           | sect571r1
+   ---------+----------+-----------+-----------
+
+   To promote interoperability, the following choices are RECOMMENDED:
+
+   Minimum  | ECDSA    | Message   | Curve
+   Bits of  | Key Size | Digest    |
+   Security |          | Algorithm |
+   ---------+----------+-----------+-----------
+   80       | 192      | SHA-256   | sect192r1
+   ---------+----------+-----------+-----------
+   112      | 224      | SHA-256   | secp224r1
+   ---------+----------+-----------+-----------
+   128      | 256      | SHA-256   | secp256r1
+   ---------+----------+-----------+-----------
+   192      | 384      | SHA-384   | secp384r1
+   ---------+----------+-----------+-----------
+   256      | 512+     | SHA-512   | secp521r1
+   ---------+----------+-----------+-----------
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 32]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+10.  IANA Considerations
+
+   This document makes extensive use of object identifiers to register
+   originator public key types and algorithms.  The algorithm object
+   identifiers are registered in the ANSI X9.62, ANSI X9.63, NIST, RSA,
+   and SECG arcs.  Additionally, object identifiers are used to identify
+   the ASN.1 modules found in Appendix A (there are two).  These are
+   defined by the SMIME WG Registrar in an arc delegated by RSA to the
+   SMIME Working Group: iso(1) member-body(2) us(840) rsadsi(113549)
+   pkcs(1) pkcs-9(9) smime(16) modules(0).  No action by IANA is
+   necessary for this document or any anticipated updates.
+
+11.  References
+
+11.1.  Normative References
+
+   [CMS]          Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+                  5652, September 2009.
+
+   [CMS-AES]      Schaad, J., "Use of the Advanced Encryption Standard
+                  (AES) Encryption Algorithm in Cryptographic Message
+                  Syntax (CMS)", RFC 3565, July 2003.
+
+   [CMS-AESCG]    Housley, R., "Using AES-CCM and AES-GCM Authenticated
+                  Encryption in the Cryptographic Message Syntax (CMS)",
+                  RFC 5084, December 2007.
+
+   [CMS-ALG]      Housley, R., "Cryptographic Message Syntax (CMS)
+                  Algorithms", RFC 3370, August 2002.
+
+   [CMS-AUTHENV]  Housley, R., "Cryptographic Message Syntax (CMS)
+                  Authenticated-Enveloped-Data Content Type", RFC 5083,
+                  November 2007.
+
+   [CMS-DH]       Rescorla, E., "Diffie-Hellman Key Agreement Method",
+                  RFC 2631, June 1999.
+
+   [CMS-SHA2]     Turner, S., "Using SHA2 Algorithms with Cryptographic
+                  Message Syntax", RFC 5754, January 2010.
+
+   [FIPS180-3]    National Institute of Standards and Technology (NIST),
+                  FIPS Publication 180-3: Secure Hash Standard, October
+                  2008.
+
+   [FIPS186-3]    National Institute of Standards and Technology (NIST),
+                  FIPS Publication 186-3: Digital Signature Standard,
+                  June 2009.
+
+
+
+
+Turner & Brown                Informational                    [Page 33]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   [HMAC-SHA2]    Nystrom, M., "Identifiers and Test Vectors for HMAC-
+                  SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-
+                  SHA-512", RFC 4231, December 2005.
+
+   [MUST]         Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [MSG]          Ramsdell, B. and S. Turner, "Secure/Multipurpose
+                  Internet Mail Extensions (S/MIME) Version 3.2 Message
+                  Specification", RFC 5751, January 2010.
+
+   [PKI]          Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+                  Housley, R., and W. Polk, "Internet X.509 Public Key
+                  Infrastructure Certificate and Certificate Revocation
+                  List (CRL) Profile", RFC 5280, May 2008.
+
+   [PKI-ALG]      Turner, S., Brown, D., Yiu, K., Housley, R., and T.
+                  Polk, "Elliptic Curve Cryptography Subject Public Key
+                  Information", RFC 5480, March 2009.
+
+   [RANDOM]       Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+                  "Randomness Requirements for Security", BCP 106, RFC
+                  4086, June 2005.
+
+   [RSAOAEP]      Schaad, J., Kaliski, B., and R. Housley, "Additional
+                  Algorithms and Identifiers for RSA Cryptography for
+                  use in the Internet X.509 Public Key Infrastructure
+                  Certificate and Certificate Revocation List (CRL)
+                  Profile", RFC 4055, June 2005.
+
+   [SEC1]         Standards for Efficient Cryptography Group, "SEC 1:
+                  Elliptic Curve Cryptography", version 2.0, May 2009,
+                  available from www.secg.org.
+
+   [SP800-56A]    National Institute of Standards and Technology (NIST),
+                  Special Publication 800-56A: Recommendation Pair-Wise
+                  Key Establishment Schemes Using Discrete Logarithm
+                  Cryptography (Revised), March 2007.
+
+   [X.680]        ITU-T Recommendation X.680 (2002) | ISO/IEC
+                  8824-1:2002. Information Technology - Abstract Syntax
+                  Notation One.
+
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 34]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+11.2.  Informative References
+
+   [BON]          D. Boneh, "The Security of Multicast MAC",
+                  Presentation at Selected Areas of Cryptography 2000,
+                  Center for Applied Cryptographic Research, University
+                  of Waterloo, 2000.  Paper version available from
+                  http://crypto.stanford.edu/~dabo/papers/mmac.ps
+
+   [CERTCAP]      Santesson, S., "X.509 Certificate Extension for
+                  Secure/Multipurpose Internet Mail Extensions (S/MIME)
+                  Capabilities", RFC 4262, December 2005.
+
+   [CMS-ASN]      Hoffman, P. and J. Schaad, "New ASN.1 Modules for CMS
+                  and S/MIME", Work in Progress, August 2009.
+
+   [CMS-ECC]      Blake-Wilson, S., Brown, D., and P. Lambert, "Use of
+                  Elliptic Curve Cryptography (ECC) Algorithms in
+                  Cryptographic Message Syntax (CMS)", RFC 3278, April
+                  2002.
+
+   [CMS-KEA]      Pawling, J., "Use of the KEA and SKIPJACK Algorithms
+                  in CMS", RFC 2876, July 2000.
+
+   [K]            B. Kaliski, "MQV Vulnerability", Posting to ANSI X9F1
+                  and IEEE P1363 newsgroups, 1998.
+
+   [PKI-ASN]      Hoffman, P. and J. Schaad, "New ASN.1 Modules for
+                  PKIX", Work in Progress, August 2009.
+
+   [SP800-57]     National Institute of Standards and Technology (NIST),
+                  Special Publication 800-57: Recommendation for Key
+                  Management - Part 1 (Revised), March 2007.
+
+   [X.681]        ITU-T Recommendation X.681 (2002) | ISO/IEC
+                  8824-2:2002. Information Technology - Abstract Syntax
+                  Notation One: Information Object Specification.
+
+   [X.682]        ITU-T Recommendation X.682 (2002) | ISO/IEC
+                  8824-3:2002. Information Technology - Abstract Syntax
+                  Notation One: Constraint Specification.
+
+   [X.683]        ITU-T Recommendation X.683 (2002) | ISO/IEC
+                  8824-4:2002. Information Technology - Abstract Syntax
+                  Notation One: Parameterization of ASN.1
+                  Specifications, 2002.
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 35]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   [X9.62]        X9.62-2005, "Public Key Cryptography for the Financial
+                  Services Industry: The Elliptic Curve Digital
+                  Signature Standard (ECDSA)", November, 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 36]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+Appendix A.   ASN.1 Modules
+
+   Appendix A.1 provides the normative ASN.1 definitions for the
+   structures described in this specification using ASN.1 as defined in
+   [X.680] for compilers that support the 1988 ASN.1.
+
+   Appendix A.2 provides informative ASN.1 definitions for the
+   structures described in this specification using ASN.1 as defined in
+   [X.680], [X.681], [X.682], and [X.683] for compilers that support the
+   2002 ASN.1.  This appendix contains the same information as Appendix
+   A.1 in a more recent (and precise) ASN.1 notation; however, Appendix
+   A.1 takes precedence in case of conflict.
+
+A.1.  1988 ASN.1 Module
+
+   CMSECCAlgs-2009-88
+     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
+       smime(16) modules(0) id-mod-cms-ecc-alg-2009-88(45) }
+
+   DEFINITIONS IMPLICIT TAGS ::=
+
+   BEGIN
+
+   -- EXPORTS ALL
+
+   IMPORTS
+
+   -- From [PKI]
+
+   AlgorithmIdentifier
+     FROM PKIX1Explicit88
+       { iso(1) identified-organization(3) dod(6)
+         internet(1) security(5) mechanisms(5) pkix(7) mod(0)
+         pkix1-explicit(18) }
+
+   -- From [RSAOAEP]
+
+   id-sha224, id-sha256, id-sha384, id-sha512
+     FROM PKIX1-PSS-OAEP-Algorithms
+       { iso(1) identified-organization(3) dod(6) internet(1)
+         security(5) mechanisms(5) pkix(7) id-mod(0)
+         id-mod-pkix1-rsa-pkalgs(33) }
+
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 37]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   -- From [PKI-ALG]
+
+   id-sha1, ecdsa-with-SHA1, ecdsa-with-SHA224,
+   ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512,
+   id-ecPublicKey, ECDSA-Sig-Value, ECPoint, ECParameters
+     FROM PKIX1Algorithms2008
+       { iso(1) identified-organization(3) dod(6) internet(1)
+         security(5) mechanisms(5) pkix(7) id-mod(0) 45 }
+
+   -- From [CMS]
+
+   OriginatorPublicKey, UserKeyingMaterial
+     FROM CryptographicMessageSyntax2004
+       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
+         smime(16) modules(0) cms-2004(24) }
+
+   -- From [CMS-ALG]
+
+   hMAC-SHA1, des-ede3-cbc, id-alg-CMS3DESwrap, CBCParameter
+     FROM CryptographicMessageSyntaxAlgorithms
+       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
+         smime(16) modules(0) cmsalg-2001(16) }
+
+   -- From [CMS-AES]
+
+   id-aes128-CBC, id-aes192-CBC, id-aes256-CBC, AES-IV,
+   id-aes128-wrap, id-aes192-wrap, id-aes256-wrap
+     FROM CMSAesRsaesOaep
+       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
+         smime(16) modules(0) id-mod-cms-aes(19) }
+
+   -- From [CMS-AESCG]
+
+   id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, CCMParameters
+   id-aes128-GCM, id-aes192-GCM, id-aes256-GCM, GCMParameters
+     FROM CMS-AES-CCM-and-AES-GCM
+       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
+         smime(16) modules(0) id-mod-cms-aes(32) }
+
+   ;
+
+   --
+   -- Message Digest Algorithms: Imported from [PKI-ALG] and [RSAOAEP]
+   --
+
+   -- id-sha1 Parameters are preferred absent
+   -- id-sha224 Parameters are preferred absent
+   -- id-sha256 Parameters are preferred absent
+
+
+
+Turner & Brown                Informational                    [Page 38]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   -- id-sha384 Parameters are preferred absent
+   -- id-sha512 Parameters are preferred absent
+
+   --
+   -- Signature Algorithms: Imported from [PKI-ALG]
+   --
+
+   -- ecdsa-with-SHA1 Parameters are NULL
+   -- ecdsa-with-SHA224 Parameters are absent
+   -- ecdsa-with-SHA256 Parameters are absent
+   -- ecdsa-with-SHA384 Parameters are absent
+   -- ecdsa-with-SHA512 Parameters are absent
+
+   -- ECDSA Signature Value
+   -- Contents of SignatureValue OCTET STRING
+
+   -- ECDSA-Sig-Value ::= SEQUENCE {
+   --   r  INTEGER,
+   --   s  INTEGER
+   -- }
+
+   --
+   -- Key Agreement Algorithms
+   --
+
+   x9-63-scheme OBJECT IDENTIFIER ::= {
+     iso(1) identified-organization(3) tc68(133) country(16) x9(840)
+     x9-63(63) schemes(0) }
+   secg-scheme OBJECT IDENTIFIER ::= {
+     iso(1) identified-organization(3) certicom(132) schemes(1) }
+
+   --
+   -- Diffie-Hellman Single Pass, Standard, with KDFs
+   --
+
+   -- Parameters are always present and indicate the key wrap algorithm
+   -- with KeyWrapAlgorithm.
+
+   dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
+     x9-63-scheme 2 }
+
+   dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
+     secg-scheme 11 0 }
+
+   dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
+     secg-scheme 11 1 }
+
+
+
+
+
+Turner & Brown                Informational                    [Page 39]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
+     secg-scheme 11 2 }
+
+   dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
+     secg-scheme 11 3 }
+
+   --
+   -- Diffie-Hellman Single Pass, Cofactor, with KDFs
+   --
+
+   dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
+     x9-63-scheme 3 }
+
+   dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
+     secg-scheme 14 0 }
+
+   dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
+     secg-scheme 14 1 }
+
+   dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
+     secg-scheme 14 2 }
+
+   dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
+     secg-scheme 14 3 }
+
+   --
+   -- MQV Single Pass, Cofactor, with KDFs
+   --
+
+   mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= {
+     x9-63-scheme 16 }
+
+   mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= {
+     secg-scheme 15 0 }
+
+   mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= {
+     secg-scheme 15 1 }
+
+   mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= {
+     secg-scheme 15 2 }
+
+   mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= {
+     secg-scheme 15 3 }
+
+   --
+   -- Key Wrap Algorithms: Imported from [CMS-ALG] and [CMS-AES]
+   --
+
+
+
+
+Turner & Brown                Informational                    [Page 40]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   KeyWrapAlgorithm ::= AlgorithmIdentifier
+
+   -- id-alg-CMS3DESwrap Parameters are NULL
+   -- id-aes128-wrap Parameters are absent
+   -- id-aes192-wrap Parameters are absent
+   -- id-aes256-wrap Parameters are absent
+
+   --
+   -- Content Encryption Algorithms: Imported from [CMS-ALG]
+   -- and [CMS-AES]
+   --
+
+   -- des-ede3-cbc Parameters are CBCParameter
+   -- id-aes128-CBC Parameters are AES-IV
+   -- id-aes192-CBC Parameters are AES-IV
+   -- id-aes256-CBC Parameters are AES-IV
+   -- id-aes128-CCM Parameters are CCMParameters
+   -- id-aes192-CCM Parameters are CCMParameters
+   -- id-aes256-CCM Parameters are CCMParameters
+   -- id-aes128-GCM Parameters are GCMParameters
+   -- id-aes192-GCM Parameters are GCMParameters
+   -- id-aes256-GCM Parameters are GCMParameters
+
+   --
+   -- Message Authentication Code Algorithms
+   --
+
+   -- hMAC-SHA1 Parameters are preferred absent
+
+   -- HMAC with SHA-224, SHA-256, SHA_384, and SHA-512 Parameters are
+   -- absent
+
+   id-hmacWithSHA224 OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549)
+     digestAlgorithm(2) 8 }
+
+   id-hmacWithSHA256 OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549)
+     digestAlgorithm(2) 9 }
+
+   id-hmacWithSHA384 OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549)
+     digestAlgorithm(2) 10 }
+
+   id-hmacWithSHA512 OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549)
+     digestAlgorithm(2) 11 }
+
+
+
+
+Turner & Brown                Informational                    [Page 41]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   --
+   -- Originator Public Key Algorithms: Imported from [PKI-ALG]
+   --
+
+   -- id-ecPublicKey Parameters are absent, NULL, or ECParameters
+
+   -- Format for both ephemeral and static public keys: Imported from
+   -- [PKI-ALG]
+
+   -- ECPoint ::= OCTET STRING
+
+   -- ECParameters ::= CHOICE {
+   --   namedCurve      OBJECT IDENTIFIER
+   --   commented out in [PKI-ALG]  implicitCurve   NULL
+   --   commented out in [PKI-ALG]  specifiedCurve  SpecifiedECDomain
+   --   commented out in [PKI-ALG]  ...
+   -- }
+       -- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
+       -- Details for SpecifiedECDomain can be found in [X9.62].
+       -- Any future additions to this CHOICE should be coordinated
+       -- with ANSI X9.
+
+   -- Format of KeyAgreeRecipientInfo ukm field when used with
+   -- ECMQV
+
+   MQVuserKeyingMaterial ::= SEQUENCE {
+     ephemeralPublicKey       OriginatorPublicKey,
+     addedukm             [0] EXPLICIT UserKeyingMaterial OPTIONAL
+   }
+
+   -- 'SharedInfo' for input to KDF when using ECDH and ECMQV with
+   -- EnvelopedData, AuthenticatedData, or AuthEnvelopedData
+
+   ECC-CMS-SharedInfo ::= SEQUENCE {
+     keyInfo         AlgorithmIdentifier,
+     entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
+     suppPubInfo [2] EXPLICIT OCTET STRING
+   }
+
+   --
+   -- S/MIME Capabilities
+   -- An identifier followed by type.
+   --
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 42]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   --
+   -- S/MIME Capabilities: Message Digest Algorithms
+   --
+
+   -- Found in [CMS-SHA2].
+
+   --
+   -- S/MIME Capabilities: Signature Algorithms
+   --
+
+   -- ecdsa-with-SHA1 Type NULL
+   -- ecdsa-with-SHA224 Type absent
+   -- ecdsa-with-SHA256 Type absent
+   -- ecdsa-with-SHA384 Type absent
+   -- ecdsa-with-SHA512 Type absent
+
+   --
+   -- S/MIME Capabilities: ECDH, Single Pass, Standard
+   --
+
+   -- dhSinglePass-stdDH-sha1kdf Type is the KeyWrapAlgorithm
+   -- dhSinglePass-stdDH-sha224kdf Type is the KeyWrapAlgorithm
+   -- dhSinglePass-stdDH-sha256kdf Type is the KeyWrapAlgorithm
+   -- dhSinglePass-stdDH-sha384kdf Type is the KeyWrapAlgorithm
+   -- dhSinglePass-stdDH-sha512kdf Type is the KeyWrapAlgorithm
+
+
+   --
+   -- S/MIME Capabilities: ECDH, Single Pass, Cofactor
+   --
+
+   -- dhSinglePass-cofactorDH-sha1kdf Type is the KeyWrapAlgorithm
+   -- dhSinglePass-cofactorDH-sha224kdf Type is the KeyWrapAlgorithm
+   -- dhSinglePass-cofactorDH-sha256kdf Type is the KeyWrapAlgorithm
+   -- dhSinglePass-cofactorDH-sha384kdf Type is the KeyWrapAlgorithm
+   -- dhSinglePass-cofactorDH-sha512kdf Type is the KeyWrapAlgorithm
+
+   --
+   -- S/MIME Capabilities: ECMQV, Single Pass, Standard
+   --
+
+   -- mqvSinglePass-sha1kdf Type is the KeyWrapAlgorithm
+   -- mqvSinglePass-sha224kdf Type is the KeyWrapAlgorithm
+   -- mqvSinglePass-sha256kdf Type is the KeyWrapAlgorithm
+   -- mqvSinglePass-sha384kdf Type is the KeyWrapAlgorithm
+   -- mqvSinglePass-sha512kdf Type is the KeyWrapAlgorithm
+
+
+
+
+
+Turner & Brown                Informational                    [Page 43]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   --
+   -- S/MIME Capabilities: Message Authentication Code Algorithms
+   --
+
+   -- hMACSHA1 Type is preferred absent
+   -- id-hmacWithSHA224 Type is absent
+   -- if-hmacWithSHA256 Type is absent
+   -- id-hmacWithSHA384 Type is absent
+   -- id-hmacWithSHA512 Type is absent
+
+   END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 44]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+A.2.  2004 ASN.1 Module
+
+CMSECCAlgs-2009-02
+  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
+    smime(16) modules(0) id-mod-cms-ecc-alg-2009-02(46) }
+
+DEFINITIONS IMPLICIT TAGS ::=
+
+BEGIN
+
+-- EXPORTS ALL
+
+IMPORTS
+
+-- From [PKI-ASN]
+
+mda-sha1, sa-ecdsaWithSHA1, sa-ecdsaWithSHA224, sa-ecdsaWithSHA256,
+sa-ecdsaWithSHA384, sa-ecdsaWithSHA512, id-ecPublicKey,
+ECDSA-Sig-Value, ECPoint, ECParameters
+  FROM PKIXAlgs-2009
+    { iso(1) identified-organization(3) dod(6) internet(1)
+      security(5) mechanisms(5) pkix(7) id-mod(0)
+      id-mod-pkix1-algorithms2008-02(56) }
+
+-- From [PKI-ASN]
+
+mda-sha224, mda-sha256, mda-sha384, mda-sha512
+  FROM PKIX1-PSS-OAEP-Algorithms-2009
+    { iso(1) identified-organization(3) dod(6) internet(1)
+      security(5) mechanisms(5) pkix(7) id-mod(0)
+      id-mod-pkix1-rsa-pkalgs-02(54) }
+
+-- FROM [CMS-ASN]
+
+KEY-WRAP, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, ALGORITHM,
+PUBLIC-KEY, MAC-ALGORITHM, CONTENT-ENCRYPTION, KEY-AGREE, SMIME-CAPS,
+AlgorithmIdentifier{}
+  FROM AlgorithmInformation-2009
+    { iso(1) identified-organization(3) dod(6) internet(1)
+      security(5) mechanisms(5) pkix(7) id-mod(0)
+      id-mod-algorithmInformation-02(58) }
+
+-- From [CMS-ASN]
+
+OriginatorPublicKey, UserKeyingMaterial
+  FROM CryptographicMessageSyntax-2009
+    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
+      smime(16) modules(0) id-mod-cms-2004-02(41) }
+
+
+
+Turner & Brown                Informational                    [Page 45]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+-- From [CMS-ASN]
+
+maca-hMAC-SHA1, cea-3DES-cbc, kwa-3DESWrap, CBCParameter
+  FROM CryptographicMessageSyntaxAlgorithms-2009
+    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
+      smime(16) modules(0) id-mod-cmsalg-2001-02(37) }
+
+-- From [CMS-ASN]
+
+cea-aes128-cbc, cea-aes192-cbc, cea-aes256-cbc, kwa-aes128-wrap,
+kwa-aes192-wrap, kwa-aes256-wrap
+  FROM CMSAesRsaesOaep-2009
+    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
+      smime(16) modules(0) id-mod-cms-aes-02(38) }
+
+-- From [CMS-ASN]
+
+cea-aes128-CCM, cea-aes192-CCM, cea-aes256-CCM, cea-aes128-GCM,
+cea-aes192-GCM, cea-aes256-GCM
+  FROM CMS-AES-CCM-and-AES-GCM-2009
+    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
+      smime(16) modules(0) id-mod-cms-aes-ccm-gcm-02(44) }
+
+;
+
+-- Constrains the SignedData digestAlgorithms field
+-- Constrains the SignedData SignerInfo digestAlgorithm field
+-- Constrains the AuthenticatedData digestAlgorithm field
+
+-- Message Digest Algorithms: Imported from [PKI-ASN]
+
+-- MessageDigestAlgs DIGEST-ALGORITHM ::= {
+--  mda-sha1   |
+--  mda-sha224 |
+--  mda-sha256 |
+--  mda-sha384 |
+--  mda-sha512,
+--  ...
+-- }
+
+-- Constrains the SignedData SignerInfo signatureAlgorithm field
+
+-- Signature Algorithms: Imported from [PKI-ASN]
+
+-- SignatureAlgs SIGNATURE-ALGORITHM ::= {
+--  sa-ecdsaWithSHA1   |
+--  sa-ecdsaWithSHA224 |
+--  sa-ecdsaWithSHA256 |
+
+
+
+Turner & Brown                Informational                    [Page 46]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+--  sa-ecdsaWithSHA384 |
+--  sa-ecdsaWithSHA512,
+--  ...
+-- }
+
+-- ECDSA Signature Value: Imported from [PKI-ALG]
+-- Contents of SignatureValue OCTET STRING
+
+-- ECDSA-Sig-Value ::= SEQUENCE {
+--   r  INTEGER,
+--   s  INTEGER
+-- }
+
+--
+-- Key Agreement Algorithms
+--
+
+-- Constrains the EnvelopedData RecipientInfo KeyAgreeRecipientInfo
+--   keyEncryption Algorithm field
+-- Constrains the AuthenticatedData RecipientInfo
+--   KeyAgreeRecipientInfo keyEncryption Algorithm field
+-- Constrains the AuthEnvelopedData RecipientInfo
+--   KeyAgreeRecipientInfo keyEncryption Algorithm field
+
+-- DH variants are not used with AuthenticatedData or
+-- AuthEnvelopedData
+
+KeyAgreementAlgs KEY-AGREE ::= {
+  kaa-dhSinglePass-stdDH-sha1kdf-scheme        |
+  kaa-dhSinglePass-stdDH-sha224kdf-scheme      |
+  kaa-dhSinglePass-stdDH-sha256kdf-scheme      |
+  kaa-dhSinglePass-stdDH-sha384kdf-scheme      |
+  kaa-dhSinglePass-stdDH-sha512kdf-scheme      |
+  kaa-dhSinglePass-cofactorDH-sha1kdf-scheme   |
+  kaa-dhSinglePass-cofactorDH-sha224kdf-scheme |
+  kaa-dhSinglePass-cofactorDH-sha256kdf-scheme |
+  kaa-dhSinglePass-cofactorDH-sha384kdf-scheme |
+  kaa-dhSinglePass-cofactorDH-sha512kdf-scheme |
+  kaa-mqvSinglePass-sha1kdf-scheme             |
+  kaa-mqvSinglePass-sha224kdf-scheme           |
+  kaa-mqvSinglePass-sha256kdf-scheme           |
+  kaa-mqvSinglePass-sha384kdf-scheme           |
+  kaa-mqvSinglePass-sha512kdf-scheme,
+  ...
+}
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 47]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+x9-63-scheme OBJECT IDENTIFIER ::= {
+  iso(1) identified-organization(3) tc68(133) country(16) x9(840)
+  x9-63(63) schemes(0) }
+
+secg-scheme OBJECT IDENTIFIER ::= {
+  iso(1) identified-organization(3) certicom(132) schemes(1) }
+
+--
+-- Diffie-Hellman Single Pass, Standard, with KDFs
+--
+
+-- Parameters are always present and indicate the Key Wrap Algorithm
+
+kaa-dhSinglePass-stdDH-sha1kdf-scheme KEY-AGREE ::= {
+  IDENTIFIER dhSinglePass-stdDH-sha1kdf-scheme
+  PARAMS TYPE KeyWrapAlgorithm ARE required
+  UKM -- TYPE unencoded data -- ARE preferredPresent
+  SMIME-CAPS cap-kaa-dhSinglePass-stdDH-sha1kdf-scheme
+}
+
+dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
+  x9-63-scheme 2 }
+
+kaa-dhSinglePass-stdDH-sha224kdf-scheme KEY-AGREE ::= {
+  IDENTIFIER dhSinglePass-stdDH-sha224kdf-scheme
+  PARAMS TYPE KeyWrapAlgorithm ARE required
+  UKM -- TYPE unencoded data -- ARE preferredPresent
+  SMIME-CAPS cap-kaa-dhSinglePass-stdDH-sha224kdf-scheme
+}
+
+dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
+  secg-scheme 11 0 }
+
+kaa-dhSinglePass-stdDH-sha256kdf-scheme KEY-AGREE ::= {
+  IDENTIFIER dhSinglePass-stdDH-sha256kdf-scheme
+  PARAMS TYPE KeyWrapAlgorithm ARE required
+  UKM -- TYPE unencoded data -- ARE preferredPresent
+  SMIME-CAPS cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme
+}
+
+dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
+  secg-scheme 11 1 }
+
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 48]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+kaa-dhSinglePass-stdDH-sha384kdf-scheme KEY-AGREE ::= {
+  IDENTIFIER dhSinglePass-stdDH-sha384kdf-scheme
+  PARAMS TYPE KeyWrapAlgorithm ARE required
+  UKM -- TYPE unencoded data -- ARE preferredPresent
+  SMIME-CAPS cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme
+}
+
+dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
+  secg-scheme 11 2 }
+
+kaa-dhSinglePass-stdDH-sha512kdf-scheme KEY-AGREE ::= {
+  IDENTIFIER dhSinglePass-stdDH-sha512kdf-scheme
+  PARAMS TYPE KeyWrapAlgorithm ARE required
+  UKM -- TYPE unencoded data -- ARE preferredPresent
+  SMIME-CAPS cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme
+}
+
+dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
+  secg-scheme 11 3 }
+
+--
+-- Diffie-Hellman Single Pass, Cofactor, with KDFs
+--
+
+kaa-dhSinglePass-cofactorDH-sha1kdf-scheme KEY-AGREE ::= {
+  IDENTIFIER dhSinglePass-cofactorDH-sha1kdf-scheme
+  PARAMS TYPE KeyWrapAlgorithm ARE required
+  UKM -- TYPE unencoded data -- ARE preferredPresent
+  SMIME-CAPS cap-kaa-dhSinglePass-cofactorDH-sha1kdf-scheme
+}
+
+dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
+  x9-63-scheme 3 }
+
+kaa-dhSinglePass-cofactorDH-sha224kdf-scheme KEY-AGREE ::= {
+  IDENTIFIER dhSinglePass-cofactorDH-sha224kdf-scheme
+  PARAMS TYPE KeyWrapAlgorithm ARE required
+  UKM -- TYPE unencoded data -- ARE preferredPresent
+  SMIME-CAPS cap-kaa-dhSinglePass-cofactorDH-sha224kdf-scheme
+}
+
+dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
+  secg-scheme 14 0 }
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 49]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+kaa-dhSinglePass-cofactorDH-sha256kdf-scheme KEY-AGREE ::= {
+  IDENTIFIER dhSinglePass-cofactorDH-sha256kdf-scheme
+  PARAMS TYPE KeyWrapAlgorithm ARE required
+  UKM -- TYPE unencoded data -- ARE preferredPresent
+  SMIME-CAPS cap-kaa-dhSinglePass-cofactorDH-sha256kdf-scheme
+}
+
+dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
+  secg-scheme 14 1 }
+
+kaa-dhSinglePass-cofactorDH-sha384kdf-scheme KEY-AGREE ::= {
+  IDENTIFIER dhSinglePass-cofactorDH-sha384kdf-scheme
+  PARAMS TYPE KeyWrapAlgorithm ARE required
+  UKM -- TYPE unencoded data -- ARE preferredPresent
+  SMIME-CAPS cap-kaa-dhSinglePass-cofactorDH-sha384kdf-scheme
+}
+
+dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
+  secg-scheme 14 2 }
+
+kaa-dhSinglePass-cofactorDH-sha512kdf-scheme KEY-AGREE ::= {
+  IDENTIFIER dhSinglePass-cofactorDH-sha512kdf-scheme
+  PARAMS TYPE KeyWrapAlgorithm ARE required
+  UKM -- TYPE unencoded data -- ARE preferredPresent
+  SMIME-CAPS cap-kaa-dhSinglePass-cofactorDH-sha512kdf-scheme
+}
+
+dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
+  secg-scheme 14 3 }
+
+--
+-- MQV Single Pass, Cofactor, with KDFs
+--
+
+kaa-mqvSinglePass-sha1kdf-scheme KEY-AGREE ::= {
+  IDENTIFIER mqvSinglePass-sha1kdf-scheme
+  PARAMS TYPE KeyWrapAlgorithm ARE required
+  UKM -- TYPE unencoded data -- ARE preferredPresent
+  SMIME-CAPS cap-kaa-mqvSinglePass-sha1kdf-scheme
+}
+
+mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= {
+  x9-63-scheme 16 }
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 50]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+kaa-mqvSinglePass-sha224kdf-scheme KEY-AGREE ::= {
+  IDENTIFIER mqvSinglePass-sha224kdf-scheme
+  PARAMS TYPE KeyWrapAlgorithm ARE required
+  UKM -- TYPE unencoded data -- ARE preferredPresent
+  SMIME-CAPS cap-kaa-mqvSinglePass-sha224kdf-scheme
+}
+
+mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= {
+  secg-scheme 15 0 }
+
+kaa-mqvSinglePass-sha256kdf-scheme KEY-AGREE ::= {
+  IDENTIFIER mqvSinglePass-sha256kdf-scheme
+  PARAMS TYPE KeyWrapAlgorithm ARE required
+  UKM -- TYPE unencoded data -- ARE preferredPresent
+  SMIME-CAPS cap-kaa-mqvSinglePass-sha256kdf-scheme
+}
+
+mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= {
+  secg-scheme 15 1 }
+
+kaa-mqvSinglePass-sha384kdf-scheme KEY-AGREE ::= {
+  IDENTIFIER mqvSinglePass-sha384kdf-scheme
+  PARAMS TYPE KeyWrapAlgorithm ARE required
+  UKM -- TYPE unencoded data -- ARE preferredPresent
+  SMIME-CAPS cap-kaa-mqvSinglePass-sha384kdf-scheme
+}
+
+mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= {
+  secg-scheme 15 2 }
+
+kaa-mqvSinglePass-sha512kdf-scheme KEY-AGREE ::= {
+  IDENTIFIER mqvSinglePass-sha512kdf-scheme
+  PARAMS TYPE KeyWrapAlgorithm ARE required
+  UKM -- TYPE unencoded data -- ARE preferredPresent
+  SMIME-CAPS cap-kaa-mqvSinglePass-sha512kdf-scheme
+}
+
+mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= {
+  secg-scheme 15 3 }
+
+--
+-- Key Wrap Algorithms: Imported from [CMS-ASN]
+--
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 51]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+KeyWrapAlgorithm ::= AlgorithmIdentifier { KEY-WRAP, { KeyWrapAlgs } }
+
+KeyWrapAlgs KEY-WRAP ::= {
+  kwa-3DESWrap    |
+  kwa-aes128-wrap |
+  kwa-aes192-wrap |
+  kwa-aes256-wrap,
+  ...
+}
+
+--
+-- Content Encryption Algorithms: Imported from [CMS-ASN]
+--
+
+-- Constrains the EnvelopedData EncryptedContentInfo encryptedContent
+-- field and the AuthEnvelopedData EncryptedContentInfo
+-- contentEncryptionAlgorithm field
+
+-- ContentEncryptionAlgs CONTENT-ENCRYPTION ::= {
+--   cea-3DES-cbc |
+--   cea-aes128-cbc   |
+--   cea-aes192-cbc   |
+--   cea-aes256-cbc   |
+--   cea-aes128-ccm   |
+--   cea-aes192-ccm   |
+--   cea-aes256-ccm   |
+--   cea-aes128-gcm   |
+--   cea-aes192-gcm   |
+--   cea-aes256-gcm,
+--   ...
+--   }
+
+-- des-ede3-cbc and aes*-cbc are used with EnvelopedData and
+-- EncryptedData
+-- aes*-ccm are used with AuthEnvelopedData
+-- aes*-gcm are used with AuthEnvelopedData
+-- (where * is 128, 192, and 256)
+
+--
+-- Message Authentication Code Algorithms
+--
+
+-- Constrains the AuthenticatedData
+-- MessageAuthenticationCodeAlgorithm field
+--
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 52]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+MessageAuthAlgs MAC-ALGORITHM ::= {
+--  maca-hMAC-SHA1 |
+  maca-hMAC-SHA224 |
+  maca-hMAC-SHA256 |
+  maca-hMAC-SHA384 |
+  maca-hMAC-SHA512,
+  ...
+}
+
+maca-hMAC-SHA224 MAC-ALGORITHM ::= {
+  IDENTIFIER id-hmacWithSHA224
+  PARAMS ARE absent
+  IS-KEYED-MAC TRUE
+  SMIME-CAPS cap-hMAC-SHA224
+}
+
+id-hmacWithSHA224 OBJECT IDENTIFIER ::= {
+  iso(1) member-body(2) us(840) rsadsi(113549)
+  digestAlgorithm(2) 8 }
+
+maca-hMAC-SHA256 MAC-ALGORITHM ::= {
+  IDENTIFIER id-hmacWithSHA256
+  PARAMS ARE absent
+  IS-KEYED-MAC TRUE
+  SMIME-CAPS cap-hMAC-SHA256
+}
+
+id-hmacWithSHA256 OBJECT IDENTIFIER ::= {
+  iso(1) member-body(2) us(840) rsadsi(113549)
+  digestAlgorithm(2) 9 }
+
+maca-hMAC-SHA384 MAC-ALGORITHM ::= {
+  IDENTIFIER id-hmacWithSHA384
+  PARAMS ARE absent
+  IS-KEYED-MAC TRUE
+  SMIME-CAPS cap-hMAC-SHA384
+}
+
+id-hmacWithSHA384 OBJECT IDENTIFIER ::= {
+  iso(1) member-body(2) us(840) rsadsi(113549)
+  digestAlgorithm(2) 10 }
+
+maca-hMAC-SHA512 MAC-ALGORITHM ::= {
+  IDENTIFIER id-hmacWithSHA512
+  PARAMS ARE absent
+  IS-KEYED-MAC TRUE
+  SMIME-CAPS cap-hMAC-SHA512
+}
+
+
+
+Turner & Brown                Informational                    [Page 53]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+id-hmacWithSHA512 OBJECT IDENTIFIER ::= {
+  iso(1) member-body(2) us(840) rsadsi(113549)
+  digestAlgorithm(2) 11 }
+
+--
+-- Originator Public Key Algorithms
+--
+
+-- Constraints on KeyAgreeRecipientInfo OriginatorIdentifierOrKey
+-- OriginatorPublicKey algorithm field
+
+OriginatorPKAlgorithms PUBLIC-KEY ::= {
+  opka-ec,
+  ...
+}
+
+opka-ec PUBLIC-KEY ::={
+  IDENTIFIER id-ecPublicKey
+  KEY ECPoint
+  PARAMS TYPE CHOICE { n NULL, p ECParameters } ARE preferredAbsent
+}
+
+-- Format for both ephemeral and static public keys: Imported from
+-- [PKI-ALG]
+
+-- ECPoint ::= OCTET STRING
+
+-- ECParameters ::= CHOICE {
+--   namedCurve      CURVE.&id({NamedCurve})
+--   commented out in [PKI-ALG] implicitCurve   NULL
+--   commented out in [PKI-ALG] specifiedCurve  SpecifiedECDomain
+--   commented out in [PKI-ALG] ...
+-- }
+  -- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
+  -- Details for SpecifiedECDomain can be found in [X9.62].
+  -- Any future additions to this CHOICE should be coordinated
+  -- with ANSI X.9.
+
+-- Format of KeyAgreeRecipientInfo ukm field when used with
+-- ECMQV
+
+MQVuserKeyingMaterial ::= SEQUENCE {
+  ephemeralPublicKey       OriginatorPublicKey,
+  addedukm             [0] EXPLICIT UserKeyingMaterial OPTIONAL
+}
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 54]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+-- 'SharedInfo' for input to KDF when using ECDH and ECMQV with
+-- EnvelopedData, AuthenticatedData, or AuthEnvelopedData
+
+ECC-CMS-SharedInfo ::= SEQUENCE {
+  keyInfo         KeyWrapAlgorithm,
+  entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
+  suppPubInfo [2] EXPLICIT OCTET STRING
+}
+
+--
+-- S/MIME CAPS for algorithms in this document
+--
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 55]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+SMimeCAPS SMIME-CAPS ::= {
+--  mda-sha1.&smimeCaps                                   |
+--  mda-sha224.&smimeCaps                                 |
+--  mda-sha256.&smimeCaps                                 |
+--  mda-sha384.&smimeCaps                                 |
+--  mda-sha512.&smimeCaps                                 |
+--  sa-ecdsaWithSHA1.&smimeCaps                           |
+--  sa-ecdsaWithSHA224.&smimeCaps                         |
+--  sa-ecdsaWithSHA256.&smimeCaps                         |
+--  sa-ecdsaWithSHA384.&smimeCaps                         |
+--  sa-ecdsaWithSHA512.&smimeCaps                         |
+  kaa-dhSinglePass-stdDH-sha1kdf-scheme.&smimeCaps        |
+  kaa-dhSinglePass-stdDH-sha224kdf-scheme.&smimeCaps      |
+  kaa-dhSinglePass-stdDH-sha256kdf-scheme.&smimeCaps      |
+  kaa-dhSinglePass-stdDH-sha384kdf-scheme.&smimeCaps      |
+  kaa-dhSinglePass-stdDH-sha512kdf-scheme.&smimeCaps      |
+  kaa-dhSinglePass-cofactorDH-sha1kdf-scheme.&smimeCaps   |
+  kaa-dhSinglePass-cofactorDH-sha224kdf-scheme.&smimeCaps |
+  kaa-dhSinglePass-cofactorDH-sha256kdf-scheme.&smimeCaps |
+  kaa-dhSinglePass-cofactorDH-sha384kdf-scheme.&smimeCaps |
+  kaa-dhSinglePass-cofactorDH-sha512kdf-scheme.&smimeCaps |
+  kaa-mqvSinglePass-sha1kdf-scheme.&smimeCaps             |
+  kaa-mqvSinglePass-sha224kdf-scheme.&smimeCaps           |
+  kaa-mqvSinglePass-sha256kdf-scheme.&smimeCaps           |
+  kaa-mqvSinglePass-sha384kdf-scheme.&smimeCaps           |
+  kaa-mqvSinglePass-sha512kdf-scheme.&smimeCaps           |
+--  kwa-3des.&smimeCaps                                   |
+--  kwa-aes128.&smimeCaps                                 |
+--  kwa-aes192.&smimeCaps                                 |
+--  kwa-aes256.&smimeCaps                                 |
+--  cea-3DES-cbc.&smimeCaps                               |
+--  cea-aes128-cbc.&smimeCaps                             |
+--  cea-aes192-cbc.&smimeCaps                             |
+--  cea-aes256-cbc.&smimeCaps                             |
+--  cea-aes128-ccm.&smimeCaps                             |
+--  cea-aes192-ccm.&smimeCaps                             |
+--  cea-aes256-ccm.&smimeCaps                             |
+--  cea-aes128-gcm.&smimeCaps                             |
+--  cea-aes192-gcm.&smimeCaps                             |
+--  cea-aes256-gcm.&smimeCaps                             |
+--  maca-hMAC-SHA1.&smimeCaps                             |
+  maca-hMAC-SHA224.&smimeCaps                             |
+  maca-hMAC-SHA256.&smimeCaps                             |
+  maca-hMAC-SHA384.&smimeCaps                             |
+  maca-hMAC-SHA512.&smimeCaps,
+  ...
+}
+
+
+
+
+Turner & Brown                Informational                    [Page 56]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+cap-kaa-dhSinglePass-stdDH-sha1kdf-scheme SMIME-CAPS ::= {
+  TYPE KeyWrapAlgorithm
+  IDENTIFIED BY dhSinglePass-stdDH-sha1kdf-scheme
+}
+
+cap-kaa-dhSinglePass-stdDH-sha224kdf-scheme SMIME-CAPS ::= {
+  TYPE KeyWrapAlgorithm
+  IDENTIFIED BY dhSinglePass-stdDH-sha224kdf-scheme
+}
+
+cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme SMIME-CAPS ::= {
+  TYPE KeyWrapAlgorithm
+  IDENTIFIED BY dhSinglePass-stdDH-sha256kdf-scheme
+}
+
+cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme SMIME-CAPS ::= {
+   TYPE KeyWrapAlgorithm
+   IDENTIFIED BY dhSinglePass-stdDH-sha384kdf-scheme
+}
+
+cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme SMIME-CAPS ::= {
+  TYPE KeyWrapAlgorithm
+  IDENTIFIED BY dhSinglePass-stdDH-sha512kdf-scheme
+}
+
+cap-kaa-dhSinglePass-cofactorDH-sha1kdf-scheme SMIME-CAPS ::={
+  TYPE KeyWrapAlgorithm
+  IDENTIFIED BY dhSinglePass-cofactorDH-sha1kdf-scheme
+}
+
+cap-kaa-dhSinglePass-cofactorDH-sha224kdf-scheme SMIME-CAPS ::={
+  TYPE KeyWrapAlgorithm
+  IDENTIFIED BY dhSinglePass-cofactorDH-sha224kdf-scheme
+}
+
+cap-kaa-dhSinglePass-cofactorDH-sha256kdf-scheme SMIME-CAPS ::={
+  TYPE KeyWrapAlgorithm
+  IDENTIFIED BY dhSinglePass-cofactorDH-sha256kdf-scheme
+}
+
+cap-kaa-dhSinglePass-cofactorDH-sha384kdf-scheme SMIME-CAPS ::={
+  TYPE KeyWrapAlgorithm
+  IDENTIFIED BY dhSinglePass-cofactorDH-sha384kdf-scheme
+}
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 57]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+cap-kaa-dhSinglePass-cofactorDH-sha512kdf-scheme SMIME-CAPS ::={
+  TYPE KeyWrapAlgorithm
+  IDENTIFIED BY dhSinglePass-cofactorDH-sha512kdf-scheme
+}
+
+cap-kaa-mqvSinglePass-sha1kdf-scheme SMIME-CAPS ::={
+  TYPE KeyWrapAlgorithm
+  IDENTIFIED BY mqvSinglePass-sha1kdf-scheme
+}
+
+cap-kaa-mqvSinglePass-sha224kdf-scheme SMIME-CAPS ::={
+  TYPE KeyWrapAlgorithm
+  IDENTIFIED BY mqvSinglePass-sha224kdf-scheme
+}
+
+cap-kaa-mqvSinglePass-sha256kdf-scheme SMIME-CAPS ::={
+  TYPE KeyWrapAlgorithm
+  IDENTIFIED BY mqvSinglePass-sha256kdf-scheme
+}
+
+cap-kaa-mqvSinglePass-sha384kdf-scheme SMIME-CAPS ::={
+  TYPE KeyWrapAlgorithm
+  IDENTIFIED BY mqvSinglePass-sha384kdf-scheme
+}
+
+cap-kaa-mqvSinglePass-sha512kdf-scheme SMIME-CAPS ::={
+  TYPE KeyWrapAlgorithm
+  IDENTIFIED BY mqvSinglePass-sha512kdf-scheme
+}
+
+cap-hMAC-SHA224 SMIME-CAPS ::={ IDENTIFIED BY id-hmacWithSHA224 }
+
+cap-hMAC-SHA256 SMIME-CAPS ::={ IDENTIFIED BY id-hmacWithSHA256 }
+
+cap-hMAC-SHA384 SMIME-CAPS ::={ IDENTIFIED BY id-hmacWithSHA384 }
+
+cap-hMAC-SHA512 SMIME-CAPS ::={ IDENTIFIED BY id-hmacWithSHA512 }
+
+END
+
+
+
+
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 58]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+Appendix B.  Changes since RFC 3278
+
+   The following summarizes the changes:
+
+   - Abstract: The basis of the document was changed to refer to NIST
+     FIPS 186-3 and SP800-56A.  However, to maintain backwards
+     compatibility the Key Derivation Function from ANSI/SEC1 is
+     retained.
+
+   - Section 1: A bullet was added to address AuthEnvelopedData.
+
+   - Section 2.1: A sentence was added to indicate FIPS180-3 is used
+     with ECDSA.  Replaced reference to ANSI X9.62 with FIPS186-3.
+
+   - Section 2.1.1: The permitted digest algorithms were expanded from
+     SHA-1 to SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512.
+
+   - Section 2.1.2 and 2.1.3: The bullet addressing integer "e" was
+     deleted.
+
+   - Section 3: Added explanation of why static-static ECDH is not
+     included.
+
+   - Section 3.1: The reference for DH was changed from RFC 3852 to RFC
+     3370.  Provided text to indicate fields of EnvelopedData are as in
+     CMS.
+
+   - Section 3.1.1: The text was updated to include description of all
+     KeyAgreeRecipientInfo fields.  Parameters for id-ecPublicKey field
+     changed from NULL to absent or ECParameter.  Additional information
+     about ukm was added.
+
+   - Section 3.2: The sentence describing the advantages of 1-Pass ECMQV
+     was rewritten.
+
+   - Section 3.2.1: The text was updated to include description of all
+     fields.  Parameters for id-ecPublicKey field changed from NULL to
+     absent or ECParameters.
+
+   - Sections 3.2.2 and 4.1.2: The re-use of ephemeral keys paragraph
+     was reworded.
+
+   - Section 4.1:  The sentences describing the advantages of 1-Pass
+     ECMQV was moved to Section 4.
+
+   - Section 4.1.2: The note about the attack was moved to Section 4.
+
+
+
+
+
+Turner & Brown                Informational                    [Page 59]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+   - Section 4.2: This section was added to address AuthEnvelopedData
+     with ECMQV.
+
+   - Section 5: This section was moved to Section 8.  The 1st paragraph
+     was modified to recommend both SignedData and EnvelopedData.  The
+     requirements were updated for hash algorithms and recommendations
+     for matching curves and hash algorithms.  Also, the requirements
+     were expanded to indicate which ECDH and ECMQV variants, key wrap
+     algorithms, and content encryption algorithms are required for each
+     of the content types used in this document.  The permitted digest
+     algorithms used in KDFs were expanded from SHA-1 to SHA-1, SHA-224,
+     SHA-256, SHA-384, and SHA-512.
+
+   - Section 6 (formerly 7): This section was updated to allow for
+     SMIMECapabilities to be present in certificates.  The S/MIME
+     capabilities for ECDSA with SHA-224, SHA-256, SHA-384, and SHA-512
+     were added to the list of S/MIME Capabilities.  Also, updated to
+     include S/MIME capabilities for ECDH and ECMQV using the SHA-224,
+     SHA-256, SHA-384, and SHA-512 algorithms as the KDF.
+
+   - Section 7.1 (formerly 8.1): Added sub-sections for digest,
+     signature, originator public key, key agreement, content
+     encryption, key wrap, and message authentication code algorithms.
+     Pointed to algorithms and parameters in appropriate documents for:
+     SHA-224, SHA-256, SHA-384, and SHA-512 as well as SHA-224, SHA-256,
+     SHA-384, and SHA-512 with ECDSA.  Also, added algorithm identifiers
+     for ECDH std, ECDH cofactor, and ECMQV with SHA-224, SHA-256,
+     SHA-384, and SHA-512 algorithms as the KDF.  Changed id-ecPublicKey
+     parameters to be absent, NULL, or ECParameters, and if present the
+     originator's ECParameters must match the recipient's ECParameters.
+
+   - Section 7.2 (formerly 8.2): Updated to include AuthEnvelopedData.
+     Also, added text to address support requirement for compressed,
+     uncompressed, and hybrid keys; changed pointers from ANSI X9.61 to
+     PKIX (where ECDSA-Sig-Value is imported); changed pointers from
+     SECG to NIST specs; and updated example of suppPubInfo to be
+     AES-256.  keyInfo's parameters changed from NULL to any associated
+     parameters (AES wraps have absent parameters).
+
+   - Section 9: Replaced text, which was a summary paragraph, with an
+     updated security considerations section.  Paragraph referring to
+     definitions of SHA-224, SHA-256, SHA-384, and SHA-512 is deleted.
+
+   - Updated references.
+
+   - Added ASN.1 modules.
+
+   - Updated acknowledgements section.
+
+
+
+Turner & Brown                Informational                    [Page 60]
+
+RFC 5753              Use of ECC Algorithms in CMS          January 2010
+
+
+Acknowledgements
+
+   The methods described in this document are based on work done by the
+   ANSI X9F1 working group.  The authors wish to extend their thanks to
+   ANSI X9F1 for their assistance.  The authors also wish to thank Peter
+   de Rooij for his patient assistance.  The technical comments of
+   Francois Rousseau were valuable contributions.
+
+   Many thanks go out to the other authors of RFC 3278: Simon Blake-
+   Wilson and Paul Lambert.  Without RFC 3278, this version wouldn't
+   exist.
+
+   The authors also wish to thank Alfred Hoenes, Jonathan Herzog, Paul
+   Hoffman, Russ Housley, and Jim Schaad for their valuable input.
+
+Authors' Addresses
+
+   Sean Turner
+   IECA, Inc.
+   3057 Nutley Street, Suite 106
+   Fairfax, VA 22031
+   USA
+
+   EMail: turners@ieca.com
+
+
+   Daniel R. L. Brown
+   Certicom Corp
+   5520 Explorer Drive #400
+   Mississauga, ON L4W 5L1
+   Canada
+
+   EMail: dbrown@certicom.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Turner & Brown                Informational                    [Page 61]
+
diff --git a/const-oid/oiddbgen/src/main.rs b/const-oid/oiddbgen/src/main.rs
index f66df6a82..64beb069f 100644
--- a/const-oid/oiddbgen/src/main.rs
+++ b/const-oid/oiddbgen/src/main.rs
@@ -10,6 +10,7 @@ const RFCS: &[(&str, &str)] = &[
     ("rfc2985", include_str!("../rfc2985.txt")),
     ("rfc3161", include_str!("../rfc3161.txt")),
     ("rfc5280", include_str!("../rfc5280.txt")),
+    ("rfc5753", include_str!("../rfc5753.txt")),
     ("rfc5911", include_str!("../rfc5911.txt")),
     ("rfc5912", include_str!("../rfc5912.txt")),
     ("rfc6268", include_str!("../rfc6268.txt")),
diff --git a/const-oid/src/db/gen.rs b/const-oid/src/db/gen.rs
index 941b5b308..576479458 100644
--- a/const-oid/src/db/gen.rs
+++ b/const-oid/src/db/gen.rs
@@ -1867,6 +1867,54 @@ pub mod rfc5280 {
         crate::ObjectIdentifier::new_unwrap("2.5.29.9");
     pub const ID_AT: crate::ObjectIdentifier = crate::ObjectIdentifier::new_unwrap("2.5.4");
 }
+pub mod rfc5753 {
+    pub const ANSI_X_9_62: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.2.840.10045");
+    pub const ID_EC_PUBLIC_KEY: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.2.840.10045.2.1");
+    pub const ID_HMAC_WITH_SHA_384: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.2.840.113549.2.10");
+    pub const ID_HMAC_WITH_SHA_512: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.2.840.113549.2.11");
+    pub const ID_HMAC_WITH_SHA_224: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.2.840.113549.2.8");
+    pub const ID_HMAC_WITH_SHA_256: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.2.840.113549.2.9");
+    pub const SECG_SCHEME: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.3.132.1");
+    pub const DH_SINGLE_PASS_STD_DH_SHA_224_KDF_SCHEME: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.3.132.1.11.0");
+    pub const DH_SINGLE_PASS_STD_DH_SHA_256_KDF_SCHEME: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.3.132.1.11.1");
+    pub const DH_SINGLE_PASS_STD_DH_SHA_384_KDF_SCHEME: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.3.132.1.11.2");
+    pub const DH_SINGLE_PASS_STD_DH_SHA_512_KDF_SCHEME: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.3.132.1.11.3");
+    pub const DH_SINGLE_PASS_COFACTOR_DH_SHA_224_KDF_SCHEME: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.3.132.1.14.0");
+    pub const DH_SINGLE_PASS_COFACTOR_DH_SHA_256_KDF_SCHEME: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.3.132.1.14.1");
+    pub const DH_SINGLE_PASS_COFACTOR_DH_SHA_384_KDF_SCHEME: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.3.132.1.14.2");
+    pub const DH_SINGLE_PASS_COFACTOR_DH_SHA_512_KDF_SCHEME: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.3.132.1.14.3");
+    pub const MQV_SINGLE_PASS_SHA_224_KDF_SCHEME: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.3.132.1.15.0");
+    pub const MQV_SINGLE_PASS_SHA_256_KDF_SCHEME: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.3.132.1.15.1");
+    pub const MQV_SINGLE_PASS_SHA_384_KDF_SCHEME: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.3.132.1.15.2");
+    pub const MQV_SINGLE_PASS_SHA_512_KDF_SCHEME: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.3.132.1.15.3");
+    pub const X_9_63_SCHEME: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.3.133.16.840.63.0");
+    pub const MQV_SINGLE_PASS_SHA_1_KDF_SCHEME: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.3.133.16.840.63.0.16");
+    pub const DH_SINGLE_PASS_STD_DH_SHA_1_KDF_SCHEME: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.3.133.16.840.63.0.2");
+    pub const DH_SINGLE_PASS_COFACTOR_DH_SHA_1_KDF_SCHEME: crate::ObjectIdentifier =
+        crate::ObjectIdentifier::new_unwrap("1.3.133.16.840.63.0.3");
+}
 pub mod rfc5911 {
     pub const ID_PBKDF_2: crate::ObjectIdentifier =
         crate::ObjectIdentifier::new_unwrap("1.2.840.113549.1.5.12");
@@ -4505,6 +4553,74 @@ pub const DB: super::Database<'static> = super::Database(&[
         "id-ce-subjectDirectoryAttributes",
     ),
     (&rfc5280::ID_AT, "id-at"),
+    (&rfc5753::ANSI_X_9_62, "ansi-x9-62"),
+    (&rfc5753::ID_EC_PUBLIC_KEY, "id-ecPublicKey"),
+    (&rfc5753::ID_HMAC_WITH_SHA_384, "id-hmacWithSHA384"),
+    (&rfc5753::ID_HMAC_WITH_SHA_512, "id-hmacWithSHA512"),
+    (&rfc5753::ID_HMAC_WITH_SHA_224, "id-hmacWithSHA224"),
+    (&rfc5753::ID_HMAC_WITH_SHA_256, "id-hmacWithSHA256"),
+    (&rfc5753::SECG_SCHEME, "secg-scheme"),
+    (
+        &rfc5753::DH_SINGLE_PASS_STD_DH_SHA_224_KDF_SCHEME,
+        "dhSinglePass-stdDH-sha224kdf-scheme",
+    ),
+    (
+        &rfc5753::DH_SINGLE_PASS_STD_DH_SHA_256_KDF_SCHEME,
+        "dhSinglePass-stdDH-sha256kdf-scheme",
+    ),
+    (
+        &rfc5753::DH_SINGLE_PASS_STD_DH_SHA_384_KDF_SCHEME,
+        "dhSinglePass-stdDH-sha384kdf-scheme",
+    ),
+    (
+        &rfc5753::DH_SINGLE_PASS_STD_DH_SHA_512_KDF_SCHEME,
+        "dhSinglePass-stdDH-sha512kdf-scheme",
+    ),
+    (
+        &rfc5753::DH_SINGLE_PASS_COFACTOR_DH_SHA_224_KDF_SCHEME,
+        "dhSinglePass-cofactorDH-sha224kdf-scheme",
+    ),
+    (
+        &rfc5753::DH_SINGLE_PASS_COFACTOR_DH_SHA_256_KDF_SCHEME,
+        "dhSinglePass-cofactorDH-sha256kdf-scheme",
+    ),
+    (
+        &rfc5753::DH_SINGLE_PASS_COFACTOR_DH_SHA_384_KDF_SCHEME,
+        "dhSinglePass-cofactorDH-sha384kdf-scheme",
+    ),
+    (
+        &rfc5753::DH_SINGLE_PASS_COFACTOR_DH_SHA_512_KDF_SCHEME,
+        "dhSinglePass-cofactorDH-sha512kdf-scheme",
+    ),
+    (
+        &rfc5753::MQV_SINGLE_PASS_SHA_224_KDF_SCHEME,
+        "mqvSinglePass-sha224kdf-scheme",
+    ),
+    (
+        &rfc5753::MQV_SINGLE_PASS_SHA_256_KDF_SCHEME,
+        "mqvSinglePass-sha256kdf-scheme",
+    ),
+    (
+        &rfc5753::MQV_SINGLE_PASS_SHA_384_KDF_SCHEME,
+        "mqvSinglePass-sha384kdf-scheme",
+    ),
+    (
+        &rfc5753::MQV_SINGLE_PASS_SHA_512_KDF_SCHEME,
+        "mqvSinglePass-sha512kdf-scheme",
+    ),
+    (&rfc5753::X_9_63_SCHEME, "x9-63-scheme"),
+    (
+        &rfc5753::MQV_SINGLE_PASS_SHA_1_KDF_SCHEME,
+        "mqvSinglePass-sha1kdf-scheme",
+    ),
+    (
+        &rfc5753::DH_SINGLE_PASS_STD_DH_SHA_1_KDF_SCHEME,
+        "dhSinglePass-stdDH-sha1kdf-scheme",
+    ),
+    (
+        &rfc5753::DH_SINGLE_PASS_COFACTOR_DH_SHA_1_KDF_SCHEME,
+        "dhSinglePass-cofactorDH-sha1kdf-scheme",
+    ),
     (&rfc5911::ID_PBKDF_2, "id-PBKDF2"),
     (&rfc5911::ID_DATA, "id-data"),
     (&rfc5911::ID_SIGNED_DATA, "id-signedData"),