Use of KYBER in the Cryptographic Message Syntax (CMS)
draft-ietf-lamps-cms-kyber-01

LAMPS                                                            J. Prat
Internet-Draft                                       CryptoNext Security
Intended status: Standards Track                            M. Ounsworth
Expires: 8 May 2024                                      Entrust Limited
                                                         5 November 2023

         Use of KYBER in the Cryptographic Message Syntax (CMS)
                     draft-ietf-lamps-cms-kyber-01

Abstract

   This document describes the conventions for using a Key Encapsulation
   Mechanism algorithm (KEM) within the Cryptographic Message Syntax
   (CMS).  The CMS specifies the envelopped-data content type, which
   consists of an encrypted content and encrypted content-encryption
   keys for one or more recipients.  The mechanism proposed here can
   rely on either post-quantum KEMs, hybrid KEMs or classical KEMs.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on 8 May 2024.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Prat & Ounsworth           Expires 8 May 2024                   [Page 1]
Internet-Draft                KYBER in CMS                 November 2023

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Revision History  . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Design Rationales . . . . . . . . . . . . . . . . . . . . . .   4
   5.  KEM Key Transport Mechanism (KEM-TRANS) . . . . . . . . . . .   5
     5.1.  Underlying Components . . . . . . . . . . . . . . . . . .   5
       5.1.1.  KEM . . . . . . . . . . . . . . . . . . . . . . . . .   5
       5.1.2.  KDF . . . . . . . . . . . . . . . . . . . . . . . . .   6
       5.1.3.  WRAP  . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Recipient's Key Generation and Distribution . . . . . . .   6
     5.3.  Sender's Operations . . . . . . . . . . . . . . . . . . .   6
     5.4.  Recipient's Operations  . . . . . . . . . . . . . . . . .   8
   6.  Use of Kyber in CMS . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Use of of Kyber within KEM-TRANS  . . . . . . . . . . . .   9
     6.2.  RecipientInfo Conventions . . . . . . . . . . . . . . . .  10
     6.3.  Certificate Conventions . . . . . . . . . . . . . . . . .  10
       6.3.1.  Key Usage Extension . . . . . . . . . . . . . . . . .  10
       6.3.2.  Subject Public Key Info . . . . . . . . . . . . . . .  11
     6.4.  SMIME Capabilities Attribute Conventions  . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   10. Annex A : ASN.1 Syntax  . . . . . . . . . . . . . . . . . . .  12
     10.1.  Annex A1 : KEM-TRANS Key Transport Mechanism . . . . . .  12
     10.2.  Annex A2 : Underlying Components . . . . . . . . . . . .  13
       10.2.1.  Key Encapsulation Mechanisms . . . . . . . . . . . .  13
       10.2.2.  Key Derivation Functions . . . . . . . . . . . . . .  14
       10.2.3.  Key Wrapping Schemes . . . . . . . . . . . . . . . .  14
     10.3.  Appendix A3 : Examples . . . . . . . . . . . . . . . . .  14
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

Prat & Ounsworth           Expires 8 May 2024                   [Page 2]
Internet-Draft                KYBER in CMS                 November 2023

1.  Revision History

   *  draft-ietf-lamps-cms-kyber-01:

      -  Details of the KEMRecipientInfo content when using Kyber;

      -  Editorial changes.

   *  draft-ietf-lamps-cms-kyber-00:

      -  Use of KEMRecipientInfo to communicate algorithm info;

      -  Editorial changes.

2.  Introduction

   In recent years, there has been a substantial amount of research on
   quantum computers -- machines that exploit quantum mechanical
   phenomena to solve mathematical problems that are difficult or
   intractable for conventional computers.  If large-scale quantum
   computers are ever built, they will be able to break many of the
   public-key cryptosystems currently in use.  This would seriously
   compromise the confidentiality and integrity of digital
   communications on the Internet and elsewhere.  Under such a threat
   model, the current key encapsulation mechanisms would be vulnerable.

   Post-quantum key encapsulation mechanisms (PQ-KEM) are being
   developed in order to provide secure key establishment against an
   adversary with access to a quantum computer.

   As the National Institute of Standards and Technology (NIST) is still
   in the process of selecting the new post-quantum cryptographic
   algorithms that are secure against both quantum and classical
   computers, the purpose of this document is to propose a generic
   "algorithm-agnostic" solution to protect in confidentiality the CMS
   envelopped-data content against the quantum threat : the KEM-TRANS
   mechanism.

   Although this mechanism could thus be used with any key encapsulation
   mechanism, including post-quantum KEMs or hybrid KEMs.

   This RFC nonetheless specifically specifies the case where the
   algorithm PQ-KEM algorithm is Kyber.

Prat & Ounsworth           Expires 8 May 2024                   [Page 3]
Internet-Draft                KYBER in CMS                 November 2023

3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The following terms are used in this document:

   BER: Basic Encoding Rules (BER) as defined in [X.690].

   DER: Distinguished Encoding Rules as defined in [X.690].

4.  Design Rationales

   The Cryptographic Message Syntax (CMS) [RFC5652] defines two levels
   of encryptions in the Envelopped-Data Content section:

   *  the Content-encryption process which protects the data using a
      symmetric algorithm used with a content encryption key (CEK);

   *  the Key-encryption process which protects this CEK using a key
      transport mechanism.

   One of the typical use case of the CMS Envelopped-Data Content is to
   randomly generate a CEK, encrypt the data with a symmetric algorithm
   using this CEK and individually send the CEK to one or more
   recipients protected by asymmetric cryptography in a RecipientInfo
   object.

   To achieve this scenario with KEM primitives, it is necessary to
   define a new key transport mechanism that will fulfil the following
   requirements:

   *  the Key Transport Mechanism SHALL be secure against quantum
      computers.

   *  the Key Transport Mechanism SHALL take the Content-Encryption Key
      (CEK) as input.

   According to NIST, a KEM generates a random secret and a ciphertext
   from which the recipient can extract the shared secret, meaning that
   a KEM can not be used straightforwardly as a key transport mechanism
   in the CMS "multi-recipients" context.  The KEM-TRANS mechanism
   defined in this document aims to turn a KEM into a key transport
   scheme allowing the sender to distribute a randomly generated key to
   several recipients.  The KEM-TRANS Key transport mechanism described

Prat & Ounsworth           Expires 8 May 2024                   [Page 4]
Internet-Draft                KYBER in CMS                 November 2023

   in the following section fulfils the requirements listed above and is
   an adaptation of the RSA-KEM algorithm previously specified in
   [RFC5990].  The solution is also aligned with the hybrid public key
   encyption scheme described in [RFC9180].

5.  KEM Key Transport Mechanism (KEM-TRANS)

   The KEM Key Transport Mechanism (KEM-TRANS) is a one-pass (store-and-
   forward) mechanism for transporting keying data to a recipient.

   With this type of mechanism, a sender cryptographically encapsulates
   the keying data using the recipient's public key to obtain encrypted
   keying data.  The recipient can then decapsulate the encrypted keying
   data using his private key to recover the plaintext keying data.

5.1.  Underlying Components

   The KEM-TRANS requires use of the following underlying components,
   which are provided to KEM-TRANS as algorithm parameters.

   *  KEM, a Key Encapsulation Mechanism;

   *  KDF, a Key Derivation Function, which derives keying data of a
      specified length from a shared secret value;

   *  WRAP, a symmetric key-wrapping scheme, which encrypts keying Data
      using a key-encrypting key (KEK).

5.1.1.  KEM

   A KEM is a cryptographic algorithm consisting of three functions :

   *  a key generation function *KEM.keygen* taking as input a security
      level and returning a key pair (private key and the associated
      public key) for this security level.

   *  an encapsulation function *KEM.encaps* taking a public key as
      input and returning a random session key and a ciphertext that is
      an encapsulation of the session key.

   *  a decaspulation function *KEM.decaps* taking as input a private
      key and a ciphertext and returning a session key.

Prat & Ounsworth           Expires 8 May 2024                   [Page 5]
Internet-Draft                KYBER in CMS                 November 2023

5.1.2.  KDF

   A key derivation function (KDF) is a cryptographic function that
   deterministically derives one or more secret keys from a secret value
   using a pseudorandom function.  KDFs can be used to stretch keys into
   longer keys or to obtain keys of a required format.

   If the session key obtained from the KEM algorithm is long enough to
   fit into the WRAP algorithm, then the KDF could be equal to the
   identity function.

5.1.3.  WRAP

   A wrapping algorithm is a symmetric algorithm protecting data in
   confidentiality and integrity.  It is especially designed to
   transport key material. the WRAP algorithm consists of two functions
   :

   *  a wrapping function *Wrap* taking a wrapping key and a plaintext
      key as input and returning a wrapped key.

   *  a decaspulation function *Unwrap* taking as input a wrapping key
      and a wraped key and returning the plaintext key.

   In the following, _kekLen_ denotes the length in bytes of the
   wrapping key for the underlying symmetric key-wrapping scheme.

   In this scheme, the length of the keying data to be transported MUST
   be among the lengths supported by the underlying symmetric key-
   wrapping scheme.

5.2.  Recipient's Key Generation and Distribution

   The KEM-TRANS described in the next sections assumes that the
   recipient has previously generated a key pair (_recipPrivKey_ and
   _recipPubKey_) and has distributed his public key to the sender.

   The protocols and mechanisms by which the key pair is securely
   generated and the public key is securely distributed are out of the
   scope of this document.

5.3.  Sender's Operations

   This process assumes that the following algorithm parameters have
   been selected:

   *  _KEM_: a key encapsulation mechanism, as defined above.

Prat & Ounsworth           Expires 8 May 2024                   [Page 6]
Internet-Draft                KYBER in CMS                 November 2023

   *  _KDF_: a key derivation function, as defined above.

   *  _Wrap_: a symmetric key-wrapping algorithm, as defined above.

   *  _kekLen_: the length in bits of the key required for the Wrap
      algorithm.

   This process assumes that the following input data has been provided:

   *  _recipPubKey_: the recipient's public key.

   *  _K_: the keying data to be transported, assumed to be a length
      that is compatible with the chosen Wrap algorithm.

   This process outputs:

   *  _EK_: the encrypted keying data, from which the recipient will be
      able to retrieve _K_.

   The sender performs the following operations:

   1.  Generate a shared secret _SS_ and the associated ciphertext _CT_
       using the KEM encaspulation function and the recipient's public
       key _recipPubKey_:

          (SS, CT) = KEM.encaps(recipPubKey)

   2.  Derive a key-encrypting key _KEK_ of length _kekLen_ bytes from
       the shared secret _SS_ using the underlying key derivation
       function:

          KEK = KDF(SS, kekLen)

   3.  Wrap the keying data _K_ with the key-encrypting key _KEK_ using
       the underlying key-wrapping scheme to obtain wrapped keying data
       _WK_ of length _wrappedKekLen_:

          WK = Wrap(KEK, K)

   4.  Concatenate the wrapped keying data _WK_ of length
       _wrappedKekLen_ and the ciphertext _CT_ to obtain the encrypted
       keying data _EK_:

          EK = (WK || CT)

   5.  Output the encrypted keying data _EK_.

Prat & Ounsworth           Expires 8 May 2024                   [Page 7]
Internet-Draft                KYBER in CMS                 November 2023

5.4.  Recipient's Operations

   This process assumes that the following algorithm parameters have
   been communicated from the sender:

   *  _KEM_: a key encapsulation mechanism, as defined above.

   *  _KDF_: a key derivation function, as defined above.

   *  _Wrap_: a symmetric key-wrapping algorithm, as defined above.

   *  _kekLen_: the length in bits of the key required for the Wrap
      algorithm.

   This process assumes that the following input data has been provided:

   *  _recipPrivKey_: the recipient's private key.

   *  _EK_: the encrypted keying data.

   This process outputs:

   *  _K_: the keying data to be transported.

   The recipient performs the following operations:

   1.  Separate the encrypted keying data _EK_ into wrapped keying data
       _WK_ of length _wrappedKekLen_ and a ciphertext _CT_ :

          (WK || CT) = EK

   2.  Decapsulate the ciphertext _CT_ using the KEM decaspulation
       function and the recipient's private key to retrieve the shared
       secret _SS_:

          SS = KEM.decaps(recipPrivKey, CT)

       If the decapsulation operation outputs an error, output
       "decryption error", and stop.

   3.  Derive a key-encrypting key _KEK_ of length _kekLen_ bytes from
       the shared secret _SS_ using the underlying key derivation
       function:

          KEK = KDF(SS, kekLen)

Prat & Ounsworth           Expires 8 May 2024                   [Page 8]
Internet-Draft                KYBER in CMS                 November 2023

   4.  Unwrap the wrapped keying data _WK_ with the key-encrypting key
       _KEK_ using the underlying key-wrapping scheme to recover the
       keying data _K_:

          K = Unwrap(KEK, WK)

       If the unwrapping operation outputs an error, output "decryption
       error", and stop.

   5.  Output the keying data _K_.

6.  Use of Kyber in CMS

   The KEM Key Transport Mechanism MAY be employed for one or more
   recipients in the CMS envelopped-data content type (Section 6 of
   [RFC5652]), where the keying data _K_ processed by the mechanism is
   the CMS content-encryption key (_CEK_).

6.1.  Use of of Kyber within KEM-TRANS

   When Kyber is employed in CMS, the security levels of the different
   underlying components used by the sender within the KEM-TRANS should
   be consistant.

   When kyber512 is used, the following configuration should be used:

   *  KEM: id-kyber512

   *  KDF: id-alg-hkdf-with-sha256 OR id-alg-hkdf-with-sha3-256

   *  kekLen: 128

   *  WRAP: id-aes128-Wrap

   When kyber768 is used, the following configuration should be used:

   *  KEM: id-kyber768

   *  KDF: id-alg-hkdf-with-sha384 OR id-alg-hkdf-with-sha3-384

   *  kekLen: 192

   *  WRAP: id-aes192-Wrap

   When kyber1024 is used, the following configuration should be used:

   *  KEM: id-kyber1024

Prat & Ounsworth           Expires 8 May 2024                   [Page 9]
Internet-Draft                KYBER in CMS                 November 2023

   *  KDF: None

   *  kekLen: 256

   *  WRAP: id-aes256-Wrap

6.2.  RecipientInfo Conventions

   When KEM-TRANS is employed for a recipient, the RecipientInfo
   alternative for that recipient MUST be OtherRecipientInfo using the
   KEMRecipientInfo structure as defined in
   [draft-ietf-lamps-cms-kemri].  The fields of the KEMRecipientInfo
   MUST have the following values:

   *  version is the syntax version number; it MUST be 0;

   *  rid identifies the recipient's certificate or public key
      (_recipPubKey_);

   *  kem identifies the KEM algorithm (_KEM_); it MUST contain one of
      the id-kyber (id-kyber512, id-kyber768, id-kyber1024);

   *  kemct is the ciphertext produced for this recipient (_CT_);

   *  kdf identifies the key-derivation algorithm (_KDF_);

   *  kekLength is the size of the key-encryption key in octets
      (_kekLen_);

   *  ukm is an optional random input to the key-derivation function;

   *  wrap identifies a key wrappingn algorithm used to encrypt the
      content-encryption key (_WRAP_).

6.3.  Certificate Conventions

   The conventions specified in this section augment [RFC5280].

6.3.1.  Key Usage Extension

   The intended application for the key MAY be indicated in the key
   usage certificate extension (see [RFC5280], Section 4.2.1.3).  If the
   keyUsage extension is present in a certificate that conveys a public
   key with the id-kem object identifier as discussed above, then the
   key usage extension MUST contain only the value _keyEncipherment_.

Prat & Ounsworth           Expires 8 May 2024                  [Page 10]
Internet-Draft                KYBER in CMS                 November 2023

   _digitalSignature_, _nonRepudiation_, _dataEncipherment_,
   _keyAgreement_, _keyCertSign_, _cRLSign_, _encipherOnly_ and
   _decipherOnly_ SHOULD NOT be present.

   A key intended to be employed only with the KEM-TRANS SHOULD NOT also
   be employed for data encryption.  Good cryptographic practice employs
   a given key pair in only one scheme.  This practice avoids the risk
   that vulnerability in one scheme may compromise the security of the
   other, and may be essential to maintain provable security.

6.3.2.  Subject Public Key Info

   If the recipient wishes to employ the KEM-TRANS with a given public
   key, the recipient MUST use a X.509 certificate as defined in
   [draft-ietf-lamps-kyber-certificates].

   The public key in the certificate should be identified by one of
   object identifiers given in Annex : id-kyber512, id-kyber768 or id-
   kyber1024.

6.4.  SMIME Capabilities Attribute Conventions

   [RFC8551], Section 2.5.2 defines the SMIMECapabilities signed
   attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be
   used to specify a partial list of algorithms that the software
   announcing the SMIMECapabilities can support.  When constructing a
   signedData object, compliant software MAY include the
   SMIMECapabilities signed attribute announcing that it supports the
   KEM Key Transport Mechanism.

   The SMIMECapability SEQUENCE representing the KEM Key Transport
   Mechanism MUST include the id-kem-trans object identifier in the
   capabilityID field and MUST include a GenericKemTransParameters value
   in the parameters field identifying the components with which the
   mechanism is to be employed.

   The DER encoding of a SMIMECapability SEQUENCE is the same as the DER
   encoding of an AlgorithmIdentifier.  Example DER encodings for
   typical sets of components are given in Appendix A.

7.  Security Considerations

   EDITOR'S NOTE' - TODO
   section to be completed

Prat & Ounsworth           Expires 8 May 2024                  [Page 11]
Internet-Draft                KYBER in CMS                 November 2023

8.  IANA Considerations

   Within the CMS, algorithms are identified by object identifiers
   (OIDs).  With one exception, all of the OIDs used in this document
   were assigned in other IETF documents, in ISO/IEC standards
   documents, by the National Institute of Standards and Technology
   (NIST).  The two exceptions are the ASN.1 module's identifier and id-
   kem-transport that are both assigned in this document.

9.  Acknowledgements

   This document incorporates contributions and comments from a large
   group of experts.  The Editors would especially like to acknowledge
   the expertise and tireless dedication of the following people, who
   attended many long meetings and generated millions of bytes of
   electronic mail and VOIP traffic over the past year in pursuit of
   this document:

   We are grateful to all, including any contributors who may have been
   inadvertently omitted from this list.

   This document borrows text from similar documents, including those
   referenced below.  Thanks to the authors of those documents..

10.  Annex A : ASN.1 Syntax

   The syntax for the scheme is given in Appendix A.1.

   The syntax for selected underlying components including those
   mentioned above is given in Appendix A.2.

   The following object identifier prefixes are used in the definitions
   below:

     nistAlgorithm OID ::= {
        joint-iso-itu-t(2) country(16) us(840) organization(1)
        gov(101) csor(3) nistAlgorithm(4)
     }

     smimeAlgorithm OID ::= { iso(1) member-body(2)
        us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3)
     }

10.1.  Annex A1 : KEM-TRANS Key Transport Mechanism

   The object identifier for the KEM Key Transport Mechanism is id-kem-
   trans, which is defined in this document as:

Prat & Ounsworth           Expires 8 May 2024                  [Page 12]
Internet-Draft                KYBER in CMS                 November 2023

   id-kem-trans OID ::= { smimeAlgorithm TBD }

   When id-kem-trans is used in an AlgorithmIdentifier, the parameters
   MUST employ the GenericKemTransParameters syntax.  The syntax for
   GenericKemTransParameters is as follows:

   GenericKemTransParameters ::= {
       kem  KeyEncapsulationMechanism,
       kdf  KeyDerivationFunction,
       wrap KeyWrappingMechanism
   }

   The fields of type GenericKemTransParameters have the following
   meanings:

   *  kem identifies the underlying key encapsulation mechanism (KEM).
      This can be Kyber.

   *  kdf identifies the underlying key derivation function (KDF).  This
      can be any KDF from [SP-800-56C-r2]. kdf can be equal to _null_ if
      the key encaspulation mechanism outputs a shared secret _SS_ of
      size _kekLen_.

   *  wrap identifies the underlying key wrapping mechanism (WRAP).
      This can be any wrapping mechanism from [RFC5649].

10.2.  Annex A2 : Underlying Components

10.2.1.  Key Encapsulation Mechanisms

   KEM-TRANS can support any NIST KEM, including the post-quantum KEM
   Kyber.  This RFC only specifies the use of Kyber.

   The object identifier for KEM depends on the security level (128
   bits, 192 bits or 256 bits)

     id-kyber512 OID ::= { nistAlgorithm TBD }
     id-kyber768 OID ::= { nistAlgorithm TBD }
     id-kyber1024 OID ::= { nistAlgorithm TBD }

   These object identifiers have no associated parameters.

     kyber512 ALGORITHM ::= { OID id-kyber512 }
     kyber768 ALGORITHM ::= { OID id-kyber768 }
     kyber1024 ALGORITHM ::= { OID id-kyber1024 }

   When one of these algorithms identifiers is used, the parameters
   field MUST be absent; not NULL but absent.

Prat & Ounsworth           Expires 8 May 2024                  [Page 13]
Internet-Draft                KYBER in CMS                 November 2023

10.2.2.  Key Derivation Functions

   This RFC only specifies the use of HKDF from [RFC5869].  The HKDF can
   be bypassed if the key encaspulation mechanism outputs a shared
   secret _SS_ of size _kekLen_. kdf is then equal to _null_.

   The object identifier for HKDF depends on the security level (128
   bits, 192 bits or 256 bits).

   For SHA2 algorithms, the following object identifiers from [RFC8619]
   should be used:

     id-alg-hkdf-with-sha256 OID ::= { OID id-alg-hkdf-with-sha256 }
     id-alg-hkdf-with-sha384 OID ::= { OID id-alg-hkdf-with-sha384 }
     id-alg-hkdf-with-sha512 OID ::= { OID id-alg-hkdf-with-sha512 }

   For SHA3 algorithms, the following object identifiers from
   [draft-housley-lamps-cms-sha3-hash] should be used:

     id-alg-hkdf-with-sha3-256 OID ::= { OID id-alg-hkdf-with-sha3-256 }
     id-alg-hkdf-with-sha3-384 OID ::= { OID id-alg-hkdf-with-sha3-384 }
     id-alg-hkdf-with-sha3-512 OID ::= { OID id-alg-hkdf-with-sha3-512 }

   When one of these algorithms identifiers is used, the parameters
   field MUST be absent; not NULL but absent.

10.2.3.  Key Wrapping Schemes

   KEM-TRANS can support any wrapping mechanism from [RFC5649].  This
   RFC only specifies the use of aes256-Wrap.

   The object identifiers for the AES Key Wrap depend on the size of the
   key-encrypting key.

   The following object identifiers from [RFC5649] should be used:

     aes128-Wrap ALGORITHM ::= { OID id-aes128-Wrap }
     aes192-Wrap ALGORITHM ::= { OID id-aes192-Wrap }
     aes256-Wrap ALGORITHM ::= { OID id-aes256-Wrap }

   When one of these algorithms identifiers is used, the parameters
   field MUST be absent; not NULL but absent.

10.3.  Appendix A3 : Examples

   EDITOR'S NOTE' - TODO
   section to be completed

Prat & Ounsworth           Expires 8 May 2024                  [Page 14]
Internet-Draft                KYBER in CMS                 November 2023

11.  References

11.1.  Normative References

   [draft-housley-lamps-cms-sha3-hash]
              IETF, "Use of the SHA3 One-way Hash Functions in the
              Cryptographic Message Syntax (CMS)", 2023.

   [draft-ietf-lamps-cms-kemri]
              IETF, "Using Key Encapsulation Mechanism (KEM) Algorithms
              in the Cryptographic Message Syntax (CMS)", 2023.

   [draft-ietf-lamps-kyber-certificates]
              IETF, "Internet X.509 Public Key Infrastructure -
              Algorithm Identifiers for Kyber", 2023.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5280]  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, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC5649]  Housley, R. and M. Dworkin, "Advanced Encryption Standard
              (AES) Key Wrap with Padding Algorithm", RFC 5649,
              DOI 10.17487/RFC5649, September 2009,
              <https://www.rfc-editor.org/info/rfc5649>.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <https://www.rfc-editor.org/info/rfc5652>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/info/rfc5869>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Prat & Ounsworth           Expires 8 May 2024                  [Page 15]
Internet-Draft                KYBER in CMS                 November 2023

   [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
              April 2019, <https://www.rfc-editor.org/info/rfc8551>.

   [RFC8619]  Housley, R., "Algorithm Identifiers for the HMAC-based
              Extract-and-Expand Key Derivation Function (HKDF)",
              RFC 8619, DOI 10.17487/RFC8619, June 2019,
              <https://www.rfc-editor.org/info/rfc8619>.

   [SP-800-56C-r2]
              NIST, "Recommendation for Key-Derivation Methods in Key-
              Establishment Schemes", 2020.

   [X.690]    ASC, "Information technology - ASN.1 encoding Rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", 2007.

11.2.  Informative References

   [RFC5990]  Randall, J., Kaliski, B., Brainard, J., and S. Turner,
              "Use of the RSA-KEM Key Transport Algorithm in the
              Cryptographic Message Syntax (CMS)", RFC 5990,
              DOI 10.17487/RFC5990, September 2010,
              <https://www.rfc-editor.org/info/rfc5990>.

   [RFC8411]  Schaad, J. and R. Andrews, "IANA Registration for the
              Cryptographic Algorithm Object Identifier Range",
              RFC 8411, DOI 10.17487/RFC8411, August 2018,
              <https://www.rfc-editor.org/info/rfc8411>.

   [RFC9180]  Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
              Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
              February 2022, <https://www.rfc-editor.org/info/rfc9180>.

   [SP-800-108]
              NIST, "Recommendation for Key Derivation Using
              Pseudorandom Functions", 2009.

Authors' Addresses

   Julien Prat
   CryptoNext Security
   Email: julien.prat@cryptonext-security.com

Prat & Ounsworth           Expires 8 May 2024                  [Page 16]
Internet-Draft                KYBER in CMS                 November 2023

   Mike Ounsworth
   Entrust Limited
   Email: mike.ounsworth@entrust.com

Prat & Ounsworth           Expires 8 May 2024                  [Page 17]