<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-lamps-cms-kemri-08" number="9629" category="std" consensus="true" submissionType="IETF" obsoletes="" updates="5652" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" prepTime="2024-08-07T15:07:04" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-kemri-08" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9629" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="CMS KEMRecipientInfo">Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)</title>
    <seriesInfo name="RFC" value="9629" stream="IETF"/>
    <author fullname="Russ Housley">
      <organization abbrev="Vigil Security" showOnFrontPage="true">Vigil Security, LLC</organization>
      <address>
        <postal>
          <city>Herndon</city>
          <region>VA</region>
          <country>United States of America</country>
        </postal>
        <email>housley@vigilsec.com</email>
      </address>
    </author>
    <author fullname="John Gray">
      <organization showOnFrontPage="true">Entrust</organization>
      <address>
        <postal>
          <city>Minneapolis</city>
          <region>MN</region>
          <country>United States of America</country>
        </postal>
        <email>john.gray@entrust.com</email>
      </address>
    </author>
    <author fullname="大久保　智史" asciiFullname="Tomofumi Okubo">
      <organization showOnFrontPage="true">Penguin Securities Pte. Ltd.</organization>
      <address>
        <postal>
          <country>Singapore</country>
        </postal>
        <email>tomofumi.okubo+ietf@gmail.com</email>
      </address>
    </author>
    <date month="08" year="2024"/>
    <area>SEC</area>
    <workgroup>lamps</workgroup>
    <keyword>kemri</keyword>
    <keyword>KEMRecipientInfo</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">The Cryptographic Message Syntax (CMS) supports key transport and
key agreement algorithms.  In recent years, cryptographers have been
specifying Key Encapsulation Mechanism (KEM) algorithms, including
quantum-secure KEM algorithms.  This document defines conventions for
the use of KEM algorithms by the originator and recipients to encrypt
and decrypt CMS content.  This document updates RFC 5652.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            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).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9629" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2024 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-asn1">ASN.1</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.3">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.3.1"><xref derivedContent="1.3" format="counter" sectionFormat="of" target="section-1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cms-version-numbers">CMS Version Numbers</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-kem-processing-overview">KEM Processing Overview</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-kem-recipient-information">KEM Recipient Information</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-kem-algorithm-identifier">KEM Algorithm Identifier</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-key-derivation">Key Derivation</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-asn1-modules">ASN.1 Modules</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-kemalgorithminformation-202">KEMAlgorithmInformation-2023 ASN.1 Module</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cms-kemrecipientinfo-2023-a">CMS-KEMRecipientInfo-2023 ASN.1 Module</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">This document updates "<xref target="RFC5652" format="title" sectionFormat="of" derivedContent="Cryptographic Message Syntax (CMS)"/>" <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/>.</t>
      <t indent="0" pn="section-1-2">The CMS enveloped-data content type
<xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/> and the CMS authenticated-enveloped-data content type
<xref target="RFC5083" format="default" sectionFormat="of" derivedContent="RFC5083"/> support both key transport and key agreement algorithms to
establish the key used to encrypt and decrypt the content.  In recent
years, cryptographers have been specifying Key Encapsulation Mechanism
(KEM) algorithms, including quantum-secure KEM algorithms.  This document
defines conventions for the use of KEM algorithms for the CMS
enveloped-data content type and the CMS authenticated-enveloped-data
content type.</t>
      <t indent="0" pn="section-1-3">A KEM algorithm is a one-pass (store-and-forward) mechanism for
transporting random keying material to a recipient using the recipient's
public key.  This means that the originator and the recipients do not need
to be online at the same time.  The recipient's private key is needed to
recover the random keying material, which is then treated as a pairwise
shared secret (ss) between the originator and recipient.</t>
      <t indent="0" pn="section-1-4">The KEMRecipientInfo structure defined in this document uses the pairwise
shared secret as an input to a key derivation function (KDF) to produce a
pairwise key-encryption key (KEK).  Then, the pairwise KEK is used to encrypt a
content-encryption key (CEK) or a content-authenticated-encryption key (CAEK)
for that recipient.  All of the recipients receive the same CEK or CAEK.</t>
      <t indent="0" pn="section-1-5">In this environment, security depends on three things.  First, the KEM algorithm
must be secure against adaptive chosen ciphertext attacks.  Second, the
key-encryption algorithm must provide confidentiality and integrity protection.  Third,
the choices of the KDF and the key-encryption algorithm need to provide the same
level of security as the KEM algorithm.</t>
      <t indent="0" pn="section-1-6">A KEM algorithm provides three functions:</t>
      <dl spacing="normal" newline="true" indent="3" pn="section-1-7">
        <dt pn="section-1-7.1">KeyGen() -&gt; (pk, sk):</dt>
        <dd pn="section-1-7.2">Generate the public key (pk) and a private key (sk).</dd>
        <dt pn="section-1-7.3">Encapsulate(pk) -&gt; (ct, ss):</dt>
        <dd pn="section-1-7.4">Given the recipient's public key (pk), produce a ciphertext (ct) to be
passed to the recipient and shared secret (ss) for the originator.</dd>
        <dt pn="section-1-7.5">Decapsulate(sk, ct) -&gt; ss:</dt>
        <dd pn="section-1-7.6">Given the private key (sk) and the ciphertext (ct), produce the
shared secret (ss) for the recipient.</dd>
      </dl>
      <t indent="0" pn="section-1-8">To support a particular KEM algorithm, the CMS originator <bcp14>MUST</bcp14> implement
the KEM Encapsulate() function.</t>
      <t indent="0" pn="section-1-9">To support a particular KEM algorithm, the CMS recipient <bcp14>MUST</bcp14> implement the KEM
KeyGen() function and the KEM Decapsulate() function.  The recipient's public key
is usually carried in a certificate <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>.</t>
      <section anchor="terms" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-terminology">Terminology</name>
        <t indent="0" pn="section-1.1-1">The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
         "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
         "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
         "<bcp14>SHOULD NOT</bcp14>",
         "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
         "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
         are to be interpreted as described in BCP 14
         <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only
         when, they appear in all capitals, as shown here.</t>
      </section>
      <section anchor="asn1" numbered="true" removeInRFC="false" toc="include" pn="section-1.2">
        <name slugifiedName="name-asn1">ASN.1</name>
        <t indent="0" pn="section-1.2-1">CMS values are generated using ASN.1 <xref target="X.680" format="default" sectionFormat="of" derivedContent="X.680"/>, which uses the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER) <xref target="X.690" format="default" sectionFormat="of" derivedContent="X.690"/>.</t>
      </section>
      <section anchor="cms-version-numbers" numbered="true" removeInRFC="false" toc="include" pn="section-1.3">
        <name slugifiedName="name-cms-version-numbers">CMS Version Numbers</name>
        <t indent="0" pn="section-1.3-1">As described in <xref section="1.3" sectionFormat="of" target="RFC5652" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5652#section-1.3" derivedContent="RFC5652"/>, the major data structures
include a version number as the first item in
the data structure.  The version number is intended to avoid ASN.1 decode
errors.  Some implementations do not check the version number prior to
attempting a decode, and then if a decode error occurs, the version
number is checked as part of the error-handling routine.  This is a
reasonable approach; it places error processing outside of the fast path.
This approach is also forgiving when an incorrect version number is used
by the originator.</t>
        <t indent="0" pn="section-1.3-2">Whenever the structure is updated, a higher version number will be
assigned.  However, to ensure maximum interoperability, the higher
version number is only used when the new syntax feature is employed.  That
is, the lowest version number that supports the generated syntax is used.</t>
      </section>
    </section>
    <section anchor="kem-processing-overview" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-kem-processing-overview">KEM Processing Overview</name>
      <t indent="0" pn="section-2-1">KEM algorithms can be used with  three CMS content types: the
enveloped-data content type <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/>, the authenticated-data
content type <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/>, or the authenticated-enveloped-data
content type <xref target="RFC5083" format="default" sectionFormat="of" derivedContent="RFC5083"/>.  For simplicity, the terminology associated
with the enveloped-data content type will be used in this overview.</t>
      <t indent="0" pn="section-2-2">The originator randomly generates the CEK (or the CAEK), and then
all recipients obtain that key as an encrypted object within the KEMRecipientInfo
encryptedKey field explained in <xref target="kemri" format="default" sectionFormat="of" derivedContent="Section 3"/>.  All recipients use
the originator-generated symmetric key to decrypt the CMS message.</t>
      <t indent="0" pn="section-2-3">A KEM algorithm and a key derivation function are used to securely
establish a pairwise symmetric KEK, which is used to encrypt
the originator-generated CEK (or the CAEK).</t>
      <t indent="0" pn="section-2-4">In advance, each recipient uses the KEM KeyGen() function to create a key pair.
The recipient will often obtain a certificate <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/> that includes the newly
generated public key.  Whether the public key is certified or not, the newly
generated public key is made available to potential originators.</t>
      <t indent="0" pn="section-2-5">The originator establishes the CEK (or the CAEK) using these steps:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2-6"><li pn="section-2-6.1" derivedCounter="1.">
          <t indent="0" pn="section-2-6.1.1">The CEK (or the CAEK) is generated at random.</t>
        </li>
        <li pn="section-2-6.2" derivedCounter="2.">
          <t indent="0" pn="section-2-6.2.1">For each recipient:  </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-6.2.2">
            <li pn="section-2-6.2.2.1">
              <t indent="0" pn="section-2-6.2.2.1.1">The recipient's public key is used with the KEM Encapsulate() function to obtain a pairwise shared secret (ss) and the ciphertext for the recipient.</t>
            </li>
            <li pn="section-2-6.2.2.2">
              <t indent="0" pn="section-2-6.2.2.2.1">The key derivation function is used to derive a pairwise symmetric KEK, from the pairwise ss and other data that is optionally sent in the ukm field.</t>
            </li>
            <li pn="section-2-6.2.2.3">
              <t indent="0" pn="section-2-6.2.2.3.1">The KEK is used to encrypt the CEK for this recipient.</t>
            </li>
          </ul>
        </li>
        <li pn="section-2-6.3" derivedCounter="3.">
          <t indent="0" pn="section-2-6.3.1">The CEK (or the CAEK) is used to encrypt the content for all recipients.</t>
        </li>
      </ol>
      <t indent="0" pn="section-2-7">The recipient obtains the CEK (or the CAEK) using these steps:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2-8"><li pn="section-2-8.1" derivedCounter="1.">
          <t indent="0" pn="section-2-8.1.1">The recipient's private key and the ciphertext are used with the KEM Decapsulate() function to obtain a pairwise ss.</t>
        </li>
        <li pn="section-2-8.2" derivedCounter="2.">
          <t indent="0" pn="section-2-8.2.1">The key derivation function is used to derive a pairwise symmetric KEK, from the pairwise ss and other data that is optionally sent in the ukm field.</t>
        </li>
        <li pn="section-2-8.3" derivedCounter="3.">
          <t indent="0" pn="section-2-8.3.1">The KEK is used to decrypt the CEK (or the CAEK).</t>
        </li>
        <li pn="section-2-8.4" derivedCounter="4.">
          <t indent="0" pn="section-2-8.4.1">The CEK (or the CAEK) is used to decrypt the content.</t>
        </li>
      </ol>
    </section>
    <section anchor="kemri" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-kem-recipient-information">KEM Recipient Information</name>
      <t indent="0" pn="section-3-1">This document defines KEMRecipientInfo for use with KEM algorithms.
As specified in <xref target="RFC5652" sectionFormat="of" section="6.2.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5652#section-6.2.5" derivedContent="RFC5652"/>,
recipient information for
additional key management techniques is represented in the
OtherRecipientInfo type. Each key management technique is identified by a unique
ASN.1 object identifier.</t>
      <t indent="0" pn="section-3-2">The object identifier associated with KEMRecipientInfo is:</t>
      <artwork align="left" pn="section-3-3">
  id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
    rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 }

  id-ori-kem OBJECT IDENTIFIER ::= { id-ori 3 }
</artwork>
      <t indent="0" pn="section-3-4">The KEMRecipientInfo type is:</t>
      <artwork align="left" pn="section-3-5">
  KEMRecipientInfo ::= SEQUENCE {
    version CMSVersion,  -- always set to 0
    rid RecipientIdentifier,
    kem KEMAlgorithmIdentifier,
    kemct OCTET STRING,
    kdf KeyDerivationAlgorithmIdentifier,
    kekLength INTEGER (1..65535),
    ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL,
    wrap KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }
</artwork>
      <t indent="0" pn="section-3-6">The fields of the KEMRecipientInfo type have the following meanings:</t>
      <t indent="3" pn="section-3-7">version is the syntax version number.  The version <bcp14>MUST</bcp14> be 0.  The
CMSVersion type is described in <xref target="RFC5652" sectionFormat="of" section="10.2.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5652#section-10.2.5" derivedContent="RFC5652"/>.</t>
      <t indent="3" pn="section-3-8">rid specifies the recipient's certificate or key that was used by
the originator with the KEM Encapsulate() function.  The
RecipientIdentifier provides two alternatives for specifying the
recipient's certificate <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>, and thereby the recipient's public
key.  The recipient's certificate <bcp14>MUST</bcp14> contain a KEM public key.  Therefore,
a recipient X.509 version 3 certificate that contains a key usage
extension <bcp14>MUST</bcp14> assert the keyEncipherment bit.  The issuerAndSerialNumber
alternative identifies the recipient's certificate by the issuer's
distinguished name and the certificate serial number; the
subjectKeyIdentifier alternative identifies the recipient's certificate by a key
identifier.  When an X.509 certificate is referenced, the key identifier
matches the X.509 subjectKeyIdentifier extension value.  When other
certificate formats are referenced, the documents that specify the certificate
format and their use with the CMS must include details on matching
the key identifier to the appropriate certificate field.  For recipient
processing, implementations <bcp14>MUST</bcp14> support both of these alternatives for
specifying the recipient's certificate.  For originator processing,
implementations <bcp14>MUST</bcp14> support at least one of these alternatives.</t>
      <t indent="3" pn="section-3-9">kem identifies the KEM algorithm, and any associated parameters, used
by the originator.  The KEMAlgorithmIdentifier is described in <xref target="kemalg" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t>
      <t indent="3" pn="section-3-10">kemct is the ciphertext produced by the KEM Encapsulate() function for
this recipient.</t>
      <t indent="3" pn="section-3-11">kdf identifies the key derivation function, and any associated parameters,
used by the originator to generate the KEK.  The
KeyDerivationAlgorithmIdentifier is described in <xref target="RFC5652" sectionFormat="of" section="10.1.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5652#section-10.1.6" derivedContent="RFC5652"/>.</t>
      <t indent="3" pn="section-3-12">kekLength is the size of the KEK in octets.  This value is one
of the inputs to the key derivation function.  The upper bound on the integer
value is provided to make it clear to implementers that support for very
large integer values is not needed.  Implementations <bcp14>MUST</bcp14> confirm that
the value provided is consistent with the key-encryption algorithm
identified in the wrap field below.</t>
      <t indent="3" pn="section-3-13">ukm is optional user keying material.  When the ukm value is provided,
it is used as part of the info structure described in <xref target="kdf" format="default" sectionFormat="of" derivedContent="Section 5"/> to
provide a context input to the key derivation function.  For example, the
ukm value could include a nonce, application-specific context information,
or an identifier for the originator.  A KEM algorithm may place
requirements on the ukm value.  Implementations that do not support the
ukm field <bcp14>SHOULD</bcp14> gracefully discontinue processing when the ukm field is
present.  Note that this requirement expands the original purpose of the
ukm described in <xref target="RFC5652" sectionFormat="of" section="10.2.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5652#section-10.2.6" derivedContent="RFC5652"/>; it is not limited to being
used with key agreement algorithms.</t>
      <t indent="3" pn="section-3-14">wrap identifies a key-encryption algorithm used to encrypt the
CEK.  The KeyEncryptionAlgorithmIdentifier
is described in <xref target="RFC5652" sectionFormat="of" section="10.1.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5652#section-10.1.3" derivedContent="RFC5652"/>.</t>
      <t indent="3" pn="section-3-15">encryptedKey is the result of encrypting the CEK or the
CAEK (the content-authenticated-encryption key, as discussed in <xref target="RFC5083" format="default" sectionFormat="of" derivedContent="RFC5083"/>) with the KEK.
EncryptedKey is an OCTET STRING.</t>
    </section>
    <section anchor="kemalg" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-kem-algorithm-identifier">KEM Algorithm Identifier</name>
      <t indent="0" pn="section-4-1">The KEMAlgorithmIdentifier type identifies a KEM algorithm used to
establish a pairwise ss.  The details of establishment depend on
the KEM algorithm used.  A key derivation function is used to transform
the pairwise ss value into a KEK.</t>
      <artwork align="left" pn="section-4-2">
  KEMAlgorithmIdentifier ::= AlgorithmIdentifier{ KEM-ALGORITHM, {...} }
</artwork>
    </section>
    <section anchor="kdf" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-key-derivation">Key Derivation</name>
      <t indent="0" pn="section-5-1">This section describes the conventions of using the KDF to compute the
KEK for KEMRecipientInfo.  For simplicity, the
terminology used in the HKDF specification <xref target="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/> is used here.</t>
      <t indent="0" pn="section-5-2">Many KDFs internally employ a one-way hash function.  When this is
the case, the hash function that is used is indirectly indicated by
the KeyDerivationAlgorithmIdentifier.  Other KDFs internally employ an
encryption algorithm.  When this is the case, the encryption that is
used is indirectly indicated by the KeyDerivationAlgorithmIdentifier.</t>
      <t indent="0" pn="section-5-3">The KDF inputs are as follows:</t>
      <t indent="3" pn="section-5-4">IKM is the input keying material. It is a symmetric secret input to
the KDF. The KDF may use a hash function or an encryption algorithm
to generate a pseudorandom key. The algorithm used to derive the
IKM is dependent on the algorithm identified in the
KeyDerivationAlgorithmIdentifier.</t>
      <t indent="3" pn="section-5-5">L is the length of the output keying material in octets. L is
identified in the kekLength of the KEMRecipientInfo.  The
value is dependent on the key-encryption algorithm used;
the key-encryption algorithm is identified in the KeyEncryptionAlgorithmIdentifier.</t>
      <t indent="3" pn="section-5-6">info is contextual input to the KDF.  The DER-encoded
CMSORIforKEMOtherInfo structure is created from elements of the
KEMRecipientInfo structure.  CMSORIforKEMOtherInfo is defined as:</t>
      <artwork align="left" pn="section-5-7">
      CMSORIforKEMOtherInfo ::= SEQUENCE {
        wrap KeyEncryptionAlgorithmIdentifier,
        kekLength INTEGER (1..65535),
        ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
</artwork>
      <t indent="0" pn="section-5-8">The CMSORIforKEMOtherInfo structure contains the following:</t>
      <t indent="3" pn="section-5-9">wrap identifies a key-encryption algorithm; the output of the
key derivation function will be used as a key for this algorithm.</t>
      <t indent="3" pn="section-5-10">kekLength is the length of the KEK in octets; the
output of the key derivation function will be exactly this size.</t>
      <t indent="3" pn="section-5-11">ukm is optional user keying material; see <xref target="kemri" format="default" sectionFormat="of" derivedContent="Section 3"/>.</t>
      <t indent="0" pn="section-5-12">The KDF output is as follows:</t>
      <t indent="3" pn="section-5-13">OKM is the output keying material with the exact length of L octets.
The OKM is the KEK that is used to encrypt the CEK or the CAEK.</t>
      <t indent="0" pn="section-5-14">An acceptable KDF <bcp14>MUST</bcp14> accept an IKM, L, and info as inputs.  An acceptable
KDF <bcp14>MAY</bcp14> also accept a salt input value, which is carried as a parameter to
the KeyDerivationAlgorithmIdentifier if present.  All of these
inputs <bcp14>MUST</bcp14> influence the output of the KDF.</t>
    </section>
    <section anchor="asn1-mod" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-asn1-modules">ASN.1 Modules</name>
      <t indent="0" pn="section-6-1">This section provides two ASN.1 modules <xref target="X.680" format="default" sectionFormat="of" derivedContent="X.680"/>.  The first ASN.1
module is an extension to the AlgorithmInformation-2009 module discussed in
<xref target="RFC5912" format="default" sectionFormat="of" derivedContent="RFC5912"/>; it defines the KEM-ALGORITHM CLASS.  The second
ASN.1 module defines the structures needed to use KEM algorithms
with CMS <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/>.</t>
      <t indent="0" pn="section-6-2">The first ASN.1 module uses EXPLICIT tagging, and the second
ASN.1 module uses IMPLICIT tagging.</t>
      <t indent="0" pn="section-6-3">Both ASN.1 modules follow the conventions established in
<xref target="RFC5911" format="default" sectionFormat="of" derivedContent="RFC5911"/>, <xref target="RFC5912" format="default" sectionFormat="of" derivedContent="RFC5912"/>, and <xref target="RFC6268" format="default" sectionFormat="of" derivedContent="RFC6268"/>.</t>
      <section anchor="asn1-mod-1" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-kemalgorithminformation-202">KEMAlgorithmInformation-2023 ASN.1 Module</name>
        <sourcecode type="asn.1" markers="true" pn="section-6.1-1">
  KEMAlgorithmInformation-2023
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
          id-mod-kemAlgorithmInformation-2023(109) }

  DEFINITIONS EXPLICIT TAGS ::=
  BEGIN
  -- EXPORTS ALL;
  IMPORTS
    ParamOptions, PUBLIC-KEY, SMIME-CAPS
    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) } ;

  -- KEM-ALGORITHM
  --
  -- Describes the basic properties of a KEM algorithm
  --
  -- Suggested prefix for KEM algorithm objects is: kema-
  --
  --  &amp;id - contains the OID identifying the KEM algorithm
  --  &amp;Value - if present, contains a type definition for the kemct;
  --               if absent, implies that no ASN.1 encoding is
  --               performed on the kemct value
  --  &amp;Params - if present, contains the type for the algorithm
  --               parameters; if absent, implies no parameters
  --  &amp;paramPresence - parameter presence requirement
  --  &amp;PublicKeySet - specifies which public keys are used with
  --               this algorithm
  --  &amp;Ukm - if absent, type for user keying material
  --  &amp;ukmPresence - specifies the requirements to define the UKM
  --               field
  --  &amp;smimeCaps - contains the object describing how the S/MIME
  --               capabilities are presented.
  --
  -- Example:
  -- kema-kem-rsa KEM-ALGORITHM ::= {
  --    IDENTIFIER id-kem-rsa
  --    PARAMS TYPE RsaKemParameters ARE optional
  --    PUBLIC-KEYS { pk-rsa | pk-rsa-kem }
  --    UKM ARE optional
  --    SMIME-CAPS { TYPE GenericHybridParameters
  --        IDENTIFIED BY id-rsa-kem }
  -- }

  KEM-ALGORITHM ::= CLASS {
    &amp;id             OBJECT IDENTIFIER UNIQUE,
    &amp;Value          OPTIONAL,
    &amp;Params         OPTIONAL,
    &amp;paramPresence  ParamOptions DEFAULT absent,
    &amp;PublicKeySet   PUBLIC-KEY OPTIONAL,
    &amp;Ukm            OPTIONAL,
    &amp;ukmPresence    ParamOptions DEFAULT absent,
    &amp;smimeCaps      SMIME-CAPS OPTIONAL
  } WITH SYNTAX {
    IDENTIFIER &amp;id
    [VALUE &amp;Value]
    [PARAMS [TYPE &amp;Params] ARE &amp;paramPresence]
    [PUBLIC-KEYS &amp;PublicKeySet]
    [UKM [TYPE &amp;Ukm] ARE &amp;ukmPresence]
    [SMIME-CAPS &amp;smimeCaps]
  }

  END
</sourcecode>
      </section>
      <section anchor="asn1-mod-2" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-cms-kemrecipientinfo-2023-a">CMS-KEMRecipientInfo-2023 ASN.1 Module</name>
        <sourcecode type="asn.1" markers="true" pn="section-6.2-1">
  CMS-KEMRecipientInfo-2023
    { iso(1) member-body(2) us(840) rsadsi(113549)
      pkcs(1) pkcs-9(9) smime(16) modules(0)
      id-mod-cms-kemri-2023(77) }

  DEFINITIONS IMPLICIT TAGS ::=
  BEGIN
  -- EXPORTS ALL;
  IMPORTS
    OTHER-RECIPIENT, CMSVersion, RecipientIdentifier,
    EncryptedKey, KeyDerivationAlgorithmIdentifier,
    KeyEncryptionAlgorithmIdentifier, UserKeyingMaterial
      FROM CryptographicMessageSyntax-2010  -- RFC 6268
        { iso(1) member-body(2) us(840) rsadsi(113549)
          pkcs(1) pkcs-9(9) smime(16) modules(0)
          id-mod-cms-2009(58) }
    KEM-ALGORITHM
      FROM KEMAlgorithmInformation-2023  -- RFC 9629
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) id-mod(0)
          id-mod-kemAlgorithmInformation-2023(109) }
    AlgorithmIdentifier{}
      FROM AlgorithmInformation-2009  -- RFC 5912
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) id-mod(0)
          id-mod-algorithmInformation-02(58) } ;

  --
  -- OtherRecipientInfo Types (ori-)
  --

  SupportedOtherRecipInfo OTHER-RECIPIENT ::= { ori-KEM, ... }

  ori-KEM OTHER-RECIPIENT ::= {
    KEMRecipientInfo IDENTIFIED BY id-ori-kem }

  id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
    rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 }

  id-ori-kem OBJECT IDENTIFIER ::= { id-ori 3 }

  --
  -- KEMRecipientInfo
  --

  KEMRecipientInfo ::= SEQUENCE {
    version CMSVersion,  -- always set to 0
    rid RecipientIdentifier,
    kem KEMAlgorithmIdentifier,
    kemct OCTET STRING,
    kdf KeyDerivationAlgorithmIdentifier,
    kekLength INTEGER (1..65535),
    ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL,
    wrap KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }

  KEMAlgSet KEM-ALGORITHM ::= { ... }

  KEMAlgorithmIdentifier ::=
    AlgorithmIdentifier{ KEM-ALGORITHM, {KEMAlgSet} }

  --
  -- CMSORIforKEMOtherInfo
  --

  CMSORIforKEMOtherInfo ::= SEQUENCE {
    wrap KeyEncryptionAlgorithmIdentifier,
    kekLength INTEGER (1..65535),
    ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }

  END
</sourcecode>
      </section>
    </section>
    <section anchor="sec-cons" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">The security considerations discussed in <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/> are applicable to this document.</t>
      <t indent="0" pn="section-7-2">To be appropriate for use with this specification, the KEM algorithm <bcp14>MUST</bcp14>
explicitly be designed to be secure when the public key is used many
times.  For example, a KEM algorithm with a single-use public key is not
appropriate, because the public key is expected to be carried in a
long-lived certificate <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/> and used over and over.  Thus, KEM
algorithms that offer indistinguishability under adaptive chosen ciphertext
attack (IND-CCA2) security are appropriate.  A common design pattern for
obtaining IND-CCA2 security with public key reuse is to apply the
Fujisaki-Okamoto (FO) transform <xref target="FO" format="default" sectionFormat="of" derivedContent="FO"/> or a variant of the FO
transform <xref target="HHK" format="default" sectionFormat="of" derivedContent="HHK"/>.</t>
      <t indent="0" pn="section-7-3">The KDF <bcp14>SHOULD</bcp14> offer at least the security level of the KEM.</t>
      <t indent="0" pn="section-7-4">The choice of the key-encryption algorithm and the size of the
KEK <bcp14>SHOULD</bcp14> be made based on the security level
provided by the KEM. The key-encryption algorithm and the
KEK <bcp14>SHOULD</bcp14> offer at least the security level of
the KEM.</t>
      <t indent="0" pn="section-7-5">KEM algorithms do not provide data origin authentication; therefore, when
a KEM algorithm is used with the authenticated-data content type, the
contents are delivered with integrity from an unknown source.</t>
      <t indent="0" pn="section-7-6">Implementations <bcp14>MUST</bcp14> protect the KEM private key, the KEK, and the CEK (or the
CAEK).  Compromise of the KEM private key may
result in the disclosure of all contents protected with that KEM private key.
However, compromise of the KEK, the CEK, or the CAEK may result in disclosure
of the encrypted content of a single message.</t>
      <t indent="0" pn="section-7-7">The KEM produces the IKM input value for the KDF.  This IKM value <bcp14>MUST NOT</bcp14>
be reused for any other purpose.  Likewise, any random value used by
the KEM algorithm to produce the shared secret or its encapsulation <bcp14>MUST NOT</bcp14>
be reused for any other purpose.  That is, the originator <bcp14>MUST</bcp14> generate a
fresh KEM shared secret for each recipient in the KEMRecipientInfo
structure, including any random value used by the KEM algorithm to produce
the KEM shared secret.  In addition, the originator <bcp14>MUST</bcp14> discard the KEM shared
secret, including any random value used by the KEM algorithm to produce
the KEM shared secret, after constructing the entry in the KEMRecipientInfo
structure for the corresponding recipient.  Similarly, the recipient <bcp14>MUST</bcp14>
discard the KEM shared secret, including any random value used by the KEM
algorithm to produce the KEM shared secret, after constructing the
KEK from the KEMRecipientInfo structure.</t>
      <t indent="0" pn="section-7-8">Implementations <bcp14>MUST</bcp14> randomly generate content-encryption keys,
content-authenticated-encryption keys, and message-authentication keys.
Also, the generation of KEM key pairs relies on random numbers.  The use
of inadequate pseudorandom number generators (PRNGs) to generate these
keys can result in little or no security.  An attacker may find it much
easier to reproduce the PRNG environment that produced the keys,
searching the resulting small set of possibilities, rather than brute-force searching the whole key space.  The generation of quality random
numbers is difficult.  <xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/> offers important guidance in this area.</t>
      <t indent="0" pn="section-7-9">If the cipher and key sizes used for the key-encryption algorithm and the
content-encryption algorithm are different, the effective security is
determined by the weaker of the two algorithms.  If, for example, the
content is encrypted with AES-CBC using a 128-bit CEK and the CEK is
wrapped with AES-KEYWRAP using a 256-bit KEK, then at most 128 bits of
protection is provided.</t>
      <t indent="0" pn="section-7-10">If the cipher and key sizes used for the key-encryption algorithm and the
content-authenticated-encryption algorithm are different, the effective
security is determined by the weaker of the two algorithms.  If, for example,
the content is encrypted with AES-GCM using a 128-bit
CAEK and the CAEK is wrapped with AES-KEYWRAP using a 192-bit KEK, then at
most 128 bits of protection is provided.</t>
      <t indent="0" pn="section-7-11">If the cipher and key sizes used for the key-encryption algorithm and the
message-authentication algorithm are different, the effective security is
determined by the weaker of the two algorithms.  If, for example, the
content is authenticated with HMAC-SHA256 using a 512-bit
message-authentication key and the message-authentication key is wrapped
with AES-KEYWRAP using a 256-bit KEK, then at most 256 bits of
protection is provided.</t>
      <t indent="0" pn="section-7-12">Implementers should be aware that cryptographic algorithms, including KEM
algorithms, become weaker with time.  As new cryptoanalysis techniques are
developed and computing capabilities advance, the work factor to break a
particular cryptographic algorithm will be reduced.  As a result,
cryptographic algorithm implementations should be modular, allowing new
algorithms to be readily inserted.  That is, implementers should be prepared
for the set of supported algorithms to change over time.</t>
    </section>
    <section anchor="iana" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-8-1">For KEMRecipientInfo as defined in <xref target="kemri" format="default" sectionFormat="of" derivedContent="Section 3"/>, IANA has
      assigned the following OID in the "SMI Security for
      S/MIME Other Recipient Info Identifiers (1.2.840.113549.1.9.16.13)"
      registry:
      </t>
      <table anchor="iana-table1" align="left" pn="table-1">
        <name/>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Decimal</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
            <th align="left" colspan="1" rowspan="1">References</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">3</td>
            <td align="left" colspan="1" rowspan="1">id-ori-kem</td>
            <td align="left" colspan="1" rowspan="1">RFC 9629</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-8-3">For the ASN.1 module defined in <xref target="asn1-mod-1" format="default" sectionFormat="of" derivedContent="Section 6.1"/>, IANA has
      assigned the following OID in the "SMI Security for PKIX Module
      Identifier" registry (1.3.6.1.5.5.7.0):
      </t>
      <table anchor="iana-table2" align="left" pn="table-2">
        <name/>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Decimal</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
            <th align="left" colspan="1" rowspan="1">References</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">109</td>
            <td align="left" colspan="1" rowspan="1">id-mod-kemAlgorithmInformation-2023</td>
            <td align="left" colspan="1" rowspan="1">RFC 9629</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-8-5">For the ASN.1 module defined in <xref target="asn1-mod-2" format="default" sectionFormat="of" derivedContent="Section 6.2"/>, IANA has
      assigned the following OID in the "SMI Security for S/MIME Module
      Identifier (1.2.840.113549.1.9.16.0)" registry:
      </t>
      <table anchor="iana-table3" align="left" pn="table-3">
        <name/>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Decimal</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
            <th align="left" colspan="1" rowspan="1">References</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">77</td>
            <td align="left" colspan="1" rowspan="1">id-mod-cms-kemri-2023</td>
            <td align="left" colspan="1" rowspan="1">RFC 9629</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <references pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-9.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC5083" target="https://www.rfc-editor.org/info/rfc5083" quoteTitle="true" derivedAnchor="RFC5083">
          <front>
            <title>Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="November" year="2007"/>
            <abstract>
              <t indent="0">This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5083"/>
          <seriesInfo name="DOI" value="10.17487/RFC5083"/>
        </reference>
        <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" quoteTitle="true" derivedAnchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper"/>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <date month="May" year="2008"/>
            <abstract>
              <t indent="0">This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5652" quoteTitle="true" derivedAnchor="RFC5652">
          <front>
            <title>Cryptographic Message Syntax (CMS)</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="September" year="2009"/>
            <abstract>
              <t indent="0">This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="70"/>
          <seriesInfo name="RFC" value="5652"/>
          <seriesInfo name="DOI" value="10.17487/RFC5652"/>
        </reference>
        <reference anchor="RFC5911" target="https://www.rfc-editor.org/info/rfc5911" quoteTitle="true" derivedAnchor="RFC5911">
          <front>
            <title>New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="June" year="2010"/>
            <abstract>
              <t indent="0">The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5911"/>
          <seriesInfo name="DOI" value="10.17487/RFC5911"/>
        </reference>
        <reference anchor="RFC5912" target="https://www.rfc-editor.org/info/rfc5912" quoteTitle="true" derivedAnchor="RFC5912">
          <front>
            <title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="June" year="2010"/>
            <abstract>
              <t indent="0">The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5912"/>
          <seriesInfo name="DOI" value="10.17487/RFC5912"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680" quoteTitle="true" derivedAnchor="X.680">
          <front>
            <title>Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.680"/>
          <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
        </reference>
        <reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690" quoteTitle="true" derivedAnchor="X.690">
          <front>
            <title>Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.690"/>
          <seriesInfo name="ISO/IEC" value="8825-1:2021"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="FO" target="https://doi.org/10.1007/s00145-011-9114-1" quoteTitle="true" derivedAnchor="FO">
          <front>
            <title>Secure Integration of Asymmetric and Symmetric Encryption Schemes</title>
            <author fullname="Eiichiro Fujisaki" initials="E." surname="Fujisaki">
              <organization showOnFrontPage="true"/>
            </author>
            <author fullname="Tatsuaki Okamoto" initials="T." surname="Okamoto">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="December" year="2011"/>
          </front>
          <refcontent>Springer Science and Business Media LLC</refcontent>
          <refcontent>Journal of Cryptology, vol. 26, no. 1, pp. 80-101</refcontent>
          <seriesInfo name="DOI" value="10.1007/s00145-011-9114-1"/>
        </reference>
        <reference anchor="HHK" target="https://doi.org/10.1007/978-3-319-70500-2_12" quoteTitle="true" derivedAnchor="HHK">
          <front>
            <title>A Modular Analysis of the Fujisaki-Okamoto Transformation</title>
            <author fullname="Dennis Hofheinz" initials="D." surname="Hofheinz">
              <organization showOnFrontPage="true"/>
            </author>
            <author fullname="Kathrin Hövelmanns" initials="K." surname="Hövelmanns">
              <organization showOnFrontPage="true"/>
            </author>
            <author fullname="Eike Kiltz" initials="E." surname="Kiltz">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="November" year="2017"/>
          </front>
          <refcontent>Springer International Publishing</refcontent>
          <refcontent>Theory of Cryptography, TCC 2017, Lecture Notes in Computer Science, vol. 10677, pp. 341-371</refcontent>
          <refcontent>Print ISBN 9783319704999, Online ISBN 9783319705002</refcontent>
          <seriesInfo name="DOI" value="10.1007/978-3-319-70500-2_12"/>
        </reference>
        <reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4086" quoteTitle="true" derivedAnchor="RFC4086">
          <front>
            <title>Randomness Requirements for Security</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="J. Schiller" initials="J." surname="Schiller"/>
            <author fullname="S. Crocker" initials="S." surname="Crocker"/>
            <date month="June" year="2005"/>
            <abstract>
              <t indent="0">Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t>
              <t indent="0">Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="106"/>
          <seriesInfo name="RFC" value="4086"/>
          <seriesInfo name="DOI" value="10.17487/RFC4086"/>
        </reference>
        <reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869" quoteTitle="true" derivedAnchor="RFC5869">
          <front>
            <title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
            <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
            <author fullname="P. Eronen" initials="P." surname="Eronen"/>
            <date month="May" year="2010"/>
            <abstract>
              <t indent="0">This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5869"/>
          <seriesInfo name="DOI" value="10.17487/RFC5869"/>
        </reference>
        <reference anchor="RFC6268" target="https://www.rfc-editor.org/info/rfc6268" quoteTitle="true" derivedAnchor="RFC6268">
          <front>
            <title>Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="July" year="2011"/>
            <abstract>
              <t indent="0">The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6268"/>
          <seriesInfo name="DOI" value="10.17487/RFC6268"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgements" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">Our thanks to <contact fullname="Burt Kaliski"/> for his guidance and design review.</t>
      <t indent="0" pn="section-appendix.a-2">Our thanks to <contact fullname="Carl Wallace"/> for his careful review of the ASN.1 modules.</t>
      <t indent="0" pn="section-appendix.a-3">Our thanks to
<contact fullname="Hendrik Brockhaus"/>,
<contact fullname="Jonathan Hammell"/>,
<contact fullname="Mike Jenkins"/>,
<contact fullname="David von Oheimb"/>,
<contact fullname="Francois Rousseau"/>, and
<contact fullname="Linda Dunbar"/>
for their careful reviews and thoughtful comments.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Russ Housley">
        <organization abbrev="Vigil Security" showOnFrontPage="true">Vigil Security, LLC</organization>
        <address>
          <postal>
            <city>Herndon</city>
            <region>VA</region>
            <country>United States of America</country>
          </postal>
          <email>housley@vigilsec.com</email>
        </address>
      </author>
      <author fullname="John Gray">
        <organization showOnFrontPage="true">Entrust</organization>
        <address>
          <postal>
            <city>Minneapolis</city>
            <region>MN</region>
            <country>United States of America</country>
          </postal>
          <email>john.gray@entrust.com</email>
        </address>
      </author>
      <author fullname="大久保　智史" asciiFullname="Tomofumi Okubo">
        <organization showOnFrontPage="true">Penguin Securities Pte. Ltd.</organization>
        <address>
          <postal>
            <country>Singapore</country>
          </postal>
          <email>tomofumi.okubo+ietf@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
