<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5083 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5083.xml">
<!ENTITY RFC5652 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml">
<!ENTITY RFC5912 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml">
<!ENTITY RFC6268 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC2631 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2631.xml">
<!ENTITY RFC4086 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml">
<!ENTITY RFC5280 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5753 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5753.xml">
<!ENTITY RFC5869 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml">
<!ENTITY RFC8017 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml">
<!ENTITY RFC8619 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8619.xml">
]> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
     docName="draft-ietf-lamps-cms-mix-with-psk-07" number="8696" category="std" ipr="trust200902">
     consensus="true" ipr="trust200902" obsoletes="" updates=""
     xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.33.0 -->
  <!-- Generated by id2xml 1.5.0 on 2019-10-08T19:51:53Z -->
	<?rfc compact="yes"?>
	<?rfc text-list-symbols="-o*+"?>
	<?rfc subcompact="no"?>
	<?rfc sortrefs="no"?>
	<?rfc symrefs="yes"?>
	<?rfc strict="yes"?>
	<?rfc toc="yes"?>
  <front>
    <title abbrev="Using Pre-Shared Key (PSK) PSK in the Crypto">Using CMS">Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)</title>
    <seriesInfo name="RFC" value="8696"/>

    <author fullname="Russ Housley" initials="R." surname="Housley">
      <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
	<address><postal><street>516
      <address>
        <postal>
          <street>516 Dranesville Road</street>
	<street>Herndon, VA 20170</street>
	<street>USA</street>
          <city>Herndon</city>
<region>VA</region>
 <code>20170</code>
          <country>United States of America</country>
        </postal>
        <email>housley@vigilsec.com</email>
      </address>
    </author>
    <date month="October" month="December" year="2019"/>
	<abstract><t>

    <abstract>
      <t>
   The invention of a large-scale quantum computer would pose a serious
   challenge for the cryptographic algorithms that are widely deployed
   today.  The Cryptographic Message Syntax (CMS) supports key transport
   and key agreement algorithms that could be broken by the invention of
   such a quantum computer.  By storing communications that are
   protected with the CMS today, someone could decrypt them in the
   future when a large-scale quantum computer becomes available.  Once
   quantum-secure key management algorithms are available, the CMS will
   be extended to support the new algorithms, algorithms if the existing syntax
   does not accommodate them.  In the near-term, this  This document describes
   a mechanism to protect today's communication from the future
   invention of a large-scale quantum computer by mixing the output of
   key transport and key agreement algorithms with a pre-shared key.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sect-1"><t> anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   The invention of a large-scale quantum computer would pose a serious
   challenge for the cryptographic algorithms that are widely deployed
   today <xref target="S1994"/>. target="S1994" format="default"/>.  It is an open question whether or not it is feasible
   to build a large-scale quantum computer, and computer and, if so, when that might
   happen <xref target="NAS2019"/>. target="NAS2019" format="default"/>.  However, if such a quantum computer is invented,
   many of the cryptographic algorithms and the security protocols that
   use them would become vulnerable.</t>
      <t>
   The Cryptographic Message Syntax (CMS) <xref target="RFC5652"/><xref target="RFC5083"/> target="RFC5652" format="default"/><xref target="RFC5083" format="default"/> supports
   key transport and key agreement algorithms that could be broken by
   the invention of a large-scale quantum computer <xref target="C2PQ"/>. target="I-D.hoffman-c2pq" format="default"/>.  These
   algorithms include RSA <xref target="RFC8017"/>, target="RFC8017" format="default"/>, Diffie-Hellman <xref target="RFC2631"/>, target="RFC2631" format="default"/>, and
   Elliptic Curve Diffie-Hellman (ECDH) <xref target="RFC5753"/>. target="RFC5753" format="default"/>.  As a result, an adversary
   that stores CMS-protected communications today, today could decrypt those
   communications in the future when a large-scale quantum computer
   becomes available.</t>
      <t>
   Once quantum-secure key management algorithms are available, the CMS
   will be extended to support them, them if the existing syntax does not
      already accommodate the new algorithms.</t>

      <t>
   In the near-term, near term, this document describes a mechanism to protect
   today's communication from the future invention of a large-scale
   quantum computer by mixing the output of existing key transport and
   key agreement algorithms with a pre-shared key (PSK).  Secure
   communication can be achieved today by mixing a strong PSK with the
   output of an existing key transport algorithm, like RSA <xref target="RFC8017"/>, target="RFC8017" format="default"/>, or
   an existing key agreement algorithm, like Diffie-Hellman <xref target="RFC2631"/> target="RFC2631" format="default"/> or
   Elliptic Curve Diffie-Hellman (ECDH) <xref target="RFC5753"/>. target="RFC5753" format="default"/>.  A
   security solution that is
   believed to be quantum resistant can be achieved by using a PSK with
   sufficient entropy along with a quantum resistant quantum-resistant key derivation
   function (KDF), like HKDF an HMAC-based key derivation function
 (HKDF) <xref target="RFC5869"/>, target="RFC5869" format="default"/>, and a quantum resistant quantum-resistant
   encryption algorithm, like 256-bit AES <xref target="AES"/>. target="AES" format="default"/>.  In this way, today's
   CMS-protected communication can be resistant to an attacker with a
   large-scale quantum computer.</t>
      <t>
   In addition, there may be other reasons for including a strong PSK
   besides protection against the future invention of a large-scale
   quantum computer.  For example, there is always the possibility of a
   cryptoanalytic breakthrough on one or more of the classic public-key
   algorithm, public key
   algorithms, and there are longstanding concerns about undisclosed
   trapdoors in Diffie-Hellman parameters <xref target="FGHT2016"/>. target="FGHT2016" format="default"/>.  Inclusion of a
   strong PSK as part of the overall key management offer offers additional
   protection against these concerns.</t>
      <t>
   Note that the CMS also supports key management techniques based on
   symmetric key-encryption keys and passwords, but they are not
   discussed in this document because they are already quantum
   resistant.  The symmetric key-encryption key technique is quantum
   resistant when used with an adequate key size.  The password
   technique is quantum resistant when used with a quantum-resistant key
   derivation function and a sufficiently large password.</t>
      <section title="Terminology" anchor="sect-1.1"><t> anchor="sect-1.1" numbered="true" toc="default">
        <name>Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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
   "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in
   BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
      <section title="ASN.1" anchor="sect-1.2"><t> anchor="sect-1.2" numbered="true" toc="default">
        <name>ASN.1</name>
        <t>
   CMS values are generated using ASN.1 <xref target="X680"/>, target="X680" format="default"/>, which uses the Basic
   Encoding Rules (BER) and the Distinguished Encoding Rules (DER)
   <xref target="X690"/>.</t> target="X690" format="default"/>.</t>
      </section>
      <section title="Version Numbers" anchor="sect-1.3"><t> anchor="sect-1.3" numbered="true" toc="default">
        <name>Version Numbers</name>
        <t>
   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 decode; then, if a decode error occurs, the
   version number is checked as part of the error handling 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 sender.</t>
        <t>
   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 title="Overview" anchor="sect-2"><t> anchor="sect-2" numbered="true" toc="default">
      <name>Overview</name>
      <t>
   The CMS enveloped-data content type <xref target="RFC5652"/> target="RFC5652" format="default"/> and the CMS
   authenticated-enveloped-data content type <xref target="RFC5083"/> target="RFC5083" format="default"/> support both key
   transport and key agreement public-key public key algorithms to establish the
   key used to encrypt the content.  No restrictions are imposed on the
   key transport or key agreement public-key public key algorithms, which means
   that any key transport or key agreement algorithm can be used,
   including algorithms that are specified in the future.  In both
   cases, the sender randomly generates the content-encryption key, and
   then all recipients obtain that key.  All recipients use the sender-
   generated sender-generated symmetric content-encryption key for decryption.</t>
      <t>
   This specification defines two quantum-resistant ways to establish a
   symmetric key-encryption key, which is used to encrypt the sender-
   generated sender-generated content-encryption key.  In both cases, the PSK is used as
   one of the inputs to a key-derivation function to create a quantum-
   resistant quantum-resistant key-encryption key.  The PSK MUST <bcp14>MUST</bcp14> be distributed to the
   sender and all of the recipients by some out-of-band means that does
   not make it vulnerable to the future invention of a large-scale
   quantum computer, and an identifier MUST <bcp14>MUST</bcp14> be assigned to the PSK.  It
   is best if each PSK has a unique identifier; however, if a recipient
   has more than one PSK with the same identifier, the recipient can try
   each of them in turn.  A PSK is expected to be used with many
   messages, with a lifetime of weeks or months.</t>
      <t>
   The content-encryption key or content-authenticated-encryption key is
   quantum-resistant,
   quantum resistant, and the sender establishes it using these steps:</t>

	<t><list style="hanging" hangIndent="3">
        <t hangText="When

        <t>When using a key transport algorithm:">

	<list style="numbers">
        <t>The algorithm:</t>

        <ol spacing="normal" type="1">

            <li>The content-encryption key or the content-authenticated-
        encryption
	    content-authenticated-encryption key, called CEK, "CEK", is generated at random.</t>
        <t>The random.</li>
            <li>The key-derivation key, called KDK, "KDK", is generated at random.</t>
	<t>For random.</li>
            <li>For each recipient, the KDK is encrypted in the recipient's
         public key, then the key derivation function (KDF) KDF is used to
         mix the pre-shared key (PSK) PSK and the KDK to produce the key-
         encryption
	    key-encryption key, called KEK.</t>
	<t>The "KEK".</li>
            <li>The KEK is used to encrypt the CEK.</t>
	</list>
	</t>

	<t hangText="When CEK.</li>
          </ol>

        <t>When using a key agreement algorithm:">

	<list style="numbers">
        <t>The algorithm:</t>

          <ol spacing="normal" type="1">
            <li>The content-encryption key or the content-authenticated-
        encryption
	    content-authenticated-encryption key, called CEK, "CEK", is generated at random.</t>
	<t>For random.</li>
            <li>For each recipient, a pairwise key-encryption key,
	    called KEK1, "KEK1",
        is established using the recipient's public key and the
        sender's private key.  Note that KEK1 will be used as a key-
        derivation key.</t>
	<t>For key-derivation key.</li>
            <li>For each recipient, the key derivation function (KDF) KDF is used
        to mix the pre-shared key (PSK) PSK and the pairwise KEK1, and the
        result is called KEK2.</t>
	<t>For "KEK2".</li>
            <li>For each recipient, the pairwise KEK2 is used to encrypt the
        CEK.</t>
	</list>
	</t>

	</list>
	</t>
        CEK.</li>
          </ol>

      <t>
   As specified in Section 6.2.5 of <xref target="RFC5652"/>, target="RFC5652" sectionFormat="of" section="6.2.5"/>, recipient information for
   additional key management techniques are is represented in the
   OtherRecipientInfo type.  Two key management techniques are specified
   in this document, and they are each identified by a unique ASN.1
   object identifier.</t>
      <t>
   The first key management technique, called keyTransPSK, see "keyTransPSK" (see
   <xref target="sect-3"/>, target="sect-3" format="default"/>), uses a key transport algorithm to transfer the key-
   derivation key-derivation key from the sender to the recipient, and then the key-
   derivation key-derivation key is mixed with the PSK using a KDF.  The output of the
   KDF is the key-encryption key, which is used for the encryption of
   the content-encryption key or content-authenticated-encryption key.</t>
      <t>

   The second key management technique, called keyAgreePSK, see "keyAgreePSK" (see
   <xref target="sect-4"/>, target="sect-4" format="default"/>), uses a key agreement algorithm to establish a pairwise key-encryption key, which
 key. This pairwise key-encryption key is then mixed with the PSK using a
 KDF to produce a second pairwise key-encryption key, which is then used to
 encrypt the content-encryption key or content-authenticated-
   encryption content-authenticated-encryption key.</t>
    </section>
    <section title="keyTransPSK" anchor="sect-3"><t> anchor="sect-3" numbered="true" toc="default">
      <name>keyTransPSK</name>
      <t>
   Per-recipient information using keyTransPSK is represented in the
   KeyTransPSKRecipientInfo type, which is indicated by the id-ori-
   keyTransPSK id-ori-keyTransPSK object identifier.  Each instance of
   KeyTransPSKRecipientInfo establishes the content-encryption key or
   content-authenticated-encryption key for one or more recipients that
   have access to the same PSK.</t>
      <t>The id-ori-keyTransPSK object identifier is:</t>

	<figure><artwork><![CDATA[
      <sourcecode name="" type="asn.1"><![CDATA[
   id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
     rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 13 }

   id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 }
]]></artwork>
        </figure> ]]></sourcecode>
      <t>The KeyTransPSKRecipientInfo type is:</t>

<figure><artwork><![CDATA[
      <sourcecode name="" type="asn.1"><![CDATA[
   KeyTransPSKRecipientInfo ::= SEQUENCE {
     version CMSVersion,  -- always set to 0
     pskid PreSharedKeyIdentifier,
     kdfAlgorithm KeyDerivationAlgorithmIdentifier,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     ktris KeyTransRecipientInfos,
     encryptedKey EncryptedKey }

   PreSharedKeyIdentifier ::= OCTET STRING

   KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo
]]></artwork>
	</figure> ]]></sourcecode>
      <t>The fields of the KeyTransPSKRecipientInfo type have the following
meanings:</t>

	<t><list hangIndent="3" style="hanging"><t>

<ul>
<li>
      version is the syntax version number.  The version MUST <bcp14>MUST</bcp14> be 0.  The
      CMSVersion type is described in Section 10.2.5 of <xref target="RFC5652"/>.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t> target="RFC5652"
      sectionFormat="of" section="10.2.5"/>.</li>
<li>
      pskid is the identifier of the PSK used by the sender.  The
      identifier is an OCTET STRING, and it need not be human readable.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t> readable.</li>
<li>
      kdfAlgorithm identifies the key-derivation algorithm, algorithm and any associated parameters, parameters used by the sender to mix the key-
      derivation key-derivation key and the PSK to generate the key-encryption key.
      The KeyDerivationAlgorithmIdentifier is described in Section
      10.1.6 of <xref target="RFC5652"/>.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t> target="RFC5652" sectionFormat="of" section="10.1.6"/>.</li>
 <li>
      keyEncryptionAlgorithm identifies a key-encryption algorithm used
      to encrypt the content-encryption key.  The
      KeyEncryptionAlgorithmIdentifier is described in Section 10.1.3 of <xref target="RFC5652"/>.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t> target="RFC5652" sectionFormat="of" section="10.1.3"/>.</li>
<li>
      ktris contains one KeyTransRecipientInfo type for each recipient;
      it uses a key transport algorithm to establish the key-derivation
      key.  That is, the encryptedKey field of KeyTransRecipientInfo
      contains the key-derivation key instead of the content-encryption
      key.  KeyTransRecipientInfo is described in Section 6.2.1 of <xref target="RFC5652"/>.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t> target="RFC5652" sectionFormat="of" section="6.2.1"/>.</li>
<li>
      encryptedKey is the result of encrypting the content-encryption
      key or the content-authenticated-encryption key with the key-
      encryption key-encryption key.  EncryptedKey is an OCTET STRING.</t>

	</list>
	</t> STRING.</li>
      </ul>
    </section>
    <section title="keyAgreePSK" anchor="sect-4"><t> anchor="sect-4" numbered="true" toc="default">
      <name>keyAgreePSK</name>
      <t>
   Per-recipient information using keyAgreePSK is represented in the
   KeyAgreePSKRecipientInfo type, which is indicated by the id-ori-
   keyAgreePSK id-ori-keyAgreePSK object identifier.  Each instance of
   KeyAgreePSKRecipientInfo establishes the content-encryption key or
   content-authenticated-encryption key for one or more recipients that
   have access to the same PSK.</t>
      <t>The id-ori-keyAgreePSK object identifier is:</t>

	<figure><artwork><![CDATA[
      <sourcecode name="" type="asn.1"><![CDATA[
   id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 }
The KeyAgreePSKRecipientInfo type is:

   KeyAgreePSKRecipientInfo ::= SEQUENCE {
     version CMSVersion,  -- always set to 0
     pskid PreSharedKeyIdentifier,
     originator [0] EXPLICIT OriginatorIdentifierOrKey,
     ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
     kdfAlgorithm KeyDerivationAlgorithmIdentifier,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     recipientEncryptedKeys RecipientEncryptedKeys }
]]></artwork>
	</figure> ]]></sourcecode>
      <t>
   The fields of the KeyAgreePSKRecipientInfo type have the following meanings:</t>

	<t><list hangIndent="3" style="hanging"><t>
<ul>
<li>
      version is the syntax version number.  The version MUST <bcp14>MUST</bcp14> be 0.  The
      CMSVersion type is described in Section 10.2.5 of <xref target="RFC5652"/>.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t> target="RFC5652"
      format="default" section="10.2.5" sectionFormat="of"/>.</li>
<li>
      pskid is the identifier of the PSK used by the sender.  The
      identifier is an OCTET STRING, and it need not be human readable.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t> readable.</li>
<li>
      originator is a CHOICE with three alternatives specifying the
      sender's key agreement public key.  Implementations MUST <bcp14>MUST</bcp14> support
      all three alternatives for specifying the sender's public key.
      The sender uses their own private key and the recipient's public
      key to generate a pairwise key-encryption key.  A key derivation
      function (KDF) KDF
      is used to mix the PSK and the pairwise key-
      encryption key-encryption key to produce a second key-encryption key.  The
      OriginatorIdentifierOrKey type is described in Section 6.2.2 of <xref target="RFC5652"/>.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t> target="RFC5652" sectionFormat="of" section="6.2.2"/>.</li>
<li>
      ukm is optional.  With some key agreement algorithms, the sender
      provides a User Keying Material (UKM) to ensure that a different
      key is generated each time the same two parties generate a
      pairwise key.  Implementations MUST <bcp14>MUST</bcp14> accept a
      KeyAgreePSKRecipientInfo SEQUENCE that includes a ukm field.
      Implementations that do not support key agreement algorithms that
      make use of UKMs MUST <bcp14>MUST</bcp14> gracefully handle the presence of UKMs.  The
      UserKeyingMaterial type is described in Section 10.2.6 of <xref target="RFC5652"/>.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t> target="RFC5652" sectionFormat="of" section="10.2.6" />.</li>
<li>
      kdfAlgorithm identifies the key-derivation algorithm, algorithm and any
      associated parameters, parameters used by the sender to mix the pairwise key-
      encryption key-encryption key and the PSK to produce a second key-encryption key
      of the same length as the first one.  The
      KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of <xref target="RFC5652"/>.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t> target="RFC5652" sectionFormat="of" section="10.1.6"/>.</li>
<li>
      keyEncryptionAlgorithm identifies a key-encryption algorithm used
      to encrypt the content-encryption key or the content-
      authenticated-encryption content-authenticated-encryption key.  The
      KeyEncryptionAlgorithmIdentifier type is described in Section
      10.1.3 of <xref target="RFC5652"/>.</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t> target="RFC5652" sectionFormat="of" section="10.1.3"/>.</li>
<li>
      recipientEncryptedKeys includes a recipient identifier and
      encrypted key for one or more recipients.  The
      KeyAgreeRecipientIdentifier is a CHOICE with two alternatives
      specifying the recipient's certificate, and thereby the
      recipient's public key, that was used by the sender to generate a
      pairwise key-encryption key.  The encryptedKey is the result of
      encrypting the content-encryption key or the content-
      authenticated-encryption content-authenticated-encryption key with the second pairwise key-
      encryption key-encryption key.  EncryptedKey is an OCTET STRING.  The
      RecipientEncryptedKeys type is defined in Section 6.2.2 of <xref target="RFC5652"/>.</t>

	</list>
	</t> target="RFC5652" sectionFormat="of" section="6.2.2" />.</li>
      </ul>
    </section>
    <section title="Key Derivation" anchor="sect-5"><t> anchor="sect-5" numbered="true" toc="default">
      <name>Key Derivation</name>
      <t>
   Many key derivation functions (KDFs) 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.  HKDF
   <xref target="RFC5869"/> target="RFC5869" format="default"/> is one example of a KDF that makes use of a hash function.</t>
      <t>
   Other KDFs internally employ an encryption algorithm.  When this is
   the case, the encryption that is used is indirectly indicated by the
   KeyDerivationAlgorithmIdentifier.  For example, AES-128-CMAC can be
   used for randomness extraction in a KDF as described in <xref target="NIST2018"/>.</t> target="NIST2018" format="default"/>.</t>
      <t>
   A KDF has several input values.  This section describes the
   conventions for using the KDF to compute the key-encryption key for
   KeyTransPSKRecipientInfo and KeyAgreePSKRecipientInfo.  For
   simplicity, the terminology used in the HKDF <xref target="RFC5869"/> specification <xref target="RFC5869" format="default"/> is used here.</t>
      <t>The KDF inputs are:</t>

      <t> <list style="hanging" hangIndent="3">
      <t>IKM
<ul>
        <li>IKM is the input keying material; it is the symmetric secret input
      to the KDF.  For KeyTransPSKRecipientInfo, it is the key-
      derivation key-derivation key.  For KeyAgreePSKRecipientInfo, it is the pairwise
      key-encryption key produced by the key agreement algorithm.</t>
      </list>
      </t>

      <t> <list style="hanging" hangIndent="3">
      <t> algorithm.</li>

        <li> salt is an optional non-secret random value.  Many KDFs do not
      require a salt, and the KeyDerivationAlgorithmIdentifier
      assignments for HKDF <xref target="RFC8619"/> target="RFC8619" format="default"/> do not offer a parameter for a
      salt.  If a particular KDF requires a salt, then the salt value is
      provided as a parameter of the KeyDerivationAlgorithmIdentifier.</t>
      </list>
      </t>

      <t> <list style="hanging" hangIndent="3">
      <t>L KeyDerivationAlgorithmIdentifier.</li>

        <li>L is the length of output keying material in octets; the value
      depends on the key-encryption algorithm that will be used.  The
      algorithm is identified by the KeyEncryptionAlgorithmIdentifier.
      In addition, the OBJECT IDENTIFIER portion of the
      KeyEncryptionAlgorithmIdentifier is included in the next input
      value, called info.</t>
      </list>
      </t>

      <t> <list style="hanging" hangIndent="3">
      <t>info "info".</li>

        <li>info is optional context and application specific information.
      The DER-encoding DER encoding of CMSORIforPSKOtherInfo is used as the info
      value, and the PSK is included in this structure.  Note that
      EXPLICIT tagging is used in the ASN.1 module that defines this
      structure.  For KeyTransPSKRecipientInfo, the ENUMERATED value of
      5 is used.  For KeyAgreePSKRecipientInfo, the ENUMERATED value of
      10 is used.  CMSORIforPSKOtherInfo is defined by the following
      ASN.1 structure:	</t>
      </list>
      </t>

	<figure><artwork><![CDATA[	</li>
      </ul>
      <sourcecode name="" type="asn.1"><![CDATA[
      CMSORIforPSKOtherInfo ::= SEQUENCE {
        psk                    OCTET STRING,
        keyMgmtAlgType         ENUMERATED {
          keyTrans               (5),
          keyAgree               (10) },
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        pskLength              INTEGER (1..MAX),
        kdkLength              INTEGER (1..MAX) }
]]></artwork>
	</figure> ]]></sourcecode>
      <t>The fields of type CMSORIforPSKOtherInfo have the following
      meanings:</t>

     <t><list hangIndent="3" style="hanging"><t>
<ul>
<li>
     psk is an OCTET STRING; it contains the PSK.</t>
     </list>
     </t>

      <t><list hangIndent="3" style="hanging"><t> PSK.</li>
<li>
      keyMgmtAlgType is either set to 5 or 10.  For
      KeyTransPSKRecipientInfo, the ENUMERATED value of 5 is used.  For
      KeyAgreePSKRecipientInfo, the ENUMERATED value of 10 is used.</t>
      </list>
      </t>

      <t><list hangIndent="3" style="hanging"><t> used.</li>
<li>
      keyEncryptionAlgorithm is the KeyEncryptionAlgorithmIdentifier,
      which identifies the algorithm and provides algorithm parameters,
      if any.</t>
      </list>
      </t>

      <t><list hangIndent="3" style="hanging"><t> any.</li>
<li>
      pskLength is a positive integer; it contains the length of the PSK
      in octets.</t>
      </list>
      </t>

      <t><list hangIndent="3" style="hanging"><t> octets.</li>
<li>
      kdkLength is a positive integer; it contains the length of the
      key-derivation key in octets.  For KeyTransPSKRecipientInfo, the
      key-derivation key is generated by the sender.  For
      KeyAgreePSKRecipientInfo, the key-derivation key is the pairwise
      key-encryption key produced by the key agreement algorithm.</t>
      </list>
      </t> algorithm.</li>
      </ul>
      <t>The KDF output is:</t>

      <t><list hangIndent="3" style="hanging"><t>
<ul>
<li>
      OKM is the output keying material, which is exactly L octets.  The
      OKM is the key-encryption key that is used to encrypt the content-
      encryption content-encryption key or the content-authenticated-encryption key.</t>
      </list>
      </t> key.</li>
      </ul>
      <t>
   An acceptable KDF MUST <bcp14>MUST</bcp14> accept IKM, L, and info inputs; and an acceptable
   KDF MAY <bcp14>MAY</bcp14> also accept salt and other inputs.  All of these inputs MUST <bcp14>MUST</bcp14>
   influence the output of the KDF.  If the KDF requires a salt or other
   inputs, then those inputs MUST <bcp14>MUST</bcp14> be provided as parameters of the
   KeyDerivationAlgorithmIdentifier.</t>
    </section>
    <section title="ASN.1 Module" anchor="sect-6"><t> anchor="sect-6" numbered="true" toc="default">
      <name>ASN.1 Module</name>
      <t>
   This section contains the ASN.1 module for the two key management
   techniques defined in this document.  This module imports types from
   other ASN.1 modules that are defined in <xref target="RFC5912"/> target="RFC5912" format="default"/> and <xref target="RFC6268"/>.</t>

	<figure><artwork><![CDATA[
<CODE BEGINS> target="RFC6268" format="default"/>.</t>
      <sourcecode name="" type="asn.1" markers="true"><![CDATA[

CMSORIforPSK-2019
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
    smime(16) modules(0) id-mod-cms-ori-psk-2019(TBD0) id-mod-cms-ori-psk-2019(69) }

DEFINITIONS EXPLICIT TAGS ::=
BEGIN

-- EXPORTS All

IMPORTS

AlgorithmIdentifier{}, KEY-DERIVATION
  FROM AlgorithmInformation-2009  -- [RFC5912]
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-algorithmInformation-02(58) }

OTHER-RECIPIENT, OtherRecipientInfo, CMSVersion,
KeyTransRecipientInfo, OriginatorIdentifierOrKey,
UserKeyingMaterial, RecipientEncryptedKeys, EncryptedKey,
KeyDerivationAlgorithmIdentifier, KeyEncryptionAlgorithmIdentifier
  FROM CryptographicMessageSyntax-2010  -- [RFC6268]
    { iso(1) member-body(2) us(840) rsadsi(113549)
      pkcs(1) pkcs-9(9) smime(16) modules(0)
      id-mod-cms-2009(58) } ;
--
-- OtherRecipientInfo Types (ori-)
--

SupportedOtherRecipInfo OTHER-RECIPIENT ::= {
  ori-keyTransPSK |
  ori-keyAgreePSK,
  ... }

--
-- Key Transport with Pre-Shared Key
--

ori-keyTransPSK OTHER-RECIPIENT ::= {
  KeyTransPSKRecipientInfo IDENTIFIED BY id-ori-keyTransPSK }

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

id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 }

KeyTransPSKRecipientInfo ::= SEQUENCE {
  version CMSVersion,  -- always set to 0
  pskid PreSharedKeyIdentifier,
  kdfAlgorithm KeyDerivationAlgorithmIdentifier,
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  ktris KeyTransRecipientInfos,
  encryptedKey EncryptedKey }

PreSharedKeyIdentifier ::= OCTET STRING

KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo

--
-- Key Agreement with Pre-Shared Key
--

ori-keyAgreePSK OTHER-RECIPIENT ::= {
  KeyAgreePSKRecipientInfo IDENTIFIED BY id-ori-keyAgreePSK }

id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 }
KeyAgreePSKRecipientInfo ::= SEQUENCE {
  version CMSVersion,  -- always set to 0
  pskid PreSharedKeyIdentifier,
  originator [0] EXPLICIT OriginatorIdentifierOrKey,
  ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
  kdfAlgorithm KeyDerivationAlgorithmIdentifier,
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  recipientEncryptedKeys RecipientEncryptedKeys }

--
-- Structure to provide 'info' input to the KDF,
-- including the Pre-Shared Key
--

CMSORIforPSKOtherInfo ::= SEQUENCE {
  psk                    OCTET STRING,
  keyMgmtAlgType         ENUMERATED {
    keyTrans               (5),
    keyAgree               (10) },
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  pskLength              INTEGER (1..MAX),
  kdkLength              INTEGER (1..MAX) }

END

<CODE ENDS>
]]></artwork>
	</figure> ]]></sourcecode>
    </section>
    <section title="Security Considerations" anchor="sect-7"><t> anchor="sect-7" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   The security considerations in related to the CMS enveloped-data
   content type in <xref target="RFC5652"/> target="RFC5652" format="default"/> and the security considerations related to
   the CMS authenticated-enveloped-data content type in <xref target="RFC5083"/> target="RFC5083" format="default"/>
   continue to apply.</t>
      <t>
   Implementations of the key derivation function must compute the
   entire result, which which, in this specification specification, is a key-encryption key,
   before outputting any portion of the result.  The resulting key-
   encryption key-encryption key must be protected.  Compromise of the key-encryption
   key may result in the disclosure of all content-encryption keys or
   content-authenticated-encryption keys that were protected with that
   keying material, which material; this, in turn turn, may result in the disclosure of the
   content.  Note that there are two key-encryption keys when a PSK with
   a key agreement algorithm is used, with similar consequence consequences for the
   compromise of either one of these keys.</t>
      <t>
   Implementations must protect the pre-shared key (PSK), PSK, key transport
   private key, the agreement private key, and the key-derivation key.
   Compromise of the PSK will make the encrypted content vulnerable to
   the future invention of a large-scale quantum computer.  Compromise
   of the PSK and either the key transport private key or the agreement
   private key may result in the disclosure of all contents protected
   with that combination of keying material.  Compromise of the PSK and
   the key-derivation key may result in the disclosure of all contents
   protected with that combination of keying material.</t>
      <t>
   A large-scale quantum computer will essentially negate the security
   provided by the key transport algorithm or the key agreement
   algorithm, which means that the attacker with a large-scale quantum
   computer can discover the key-derivation key.  In addition addition, a large-
   scale large-scale quantum computer effectively cuts the security provided by a
   symmetric key algorithm in half.  Therefore, the PSK needs at least
   256 bits of entropy to provide 128 bits of security.  To match that
   same level of security, the key derivation function needs to be
   quantum-resistant
   quantum resistant and produce a key-encryption key that is at least
   256 bits in length.  Similarly, the content-encryption key or
   content-authenticated-encryption key needs to be at least 256 bits in
   length.</t>
      <t>
   When using a PSK with a key transport or a key agreement algorithm, a
   key-encryption key is produced to encrypt the content-encryption key
   or content-authenticated-encryption key.  If the key-encryption
   algorithm is different than the algorithm used to protect the
   content, then the effective security is determined by the weaker of
   the two algorithms.  If, for example, content is encrypted with
   256-bit AES, AES and the key is wrapped with 128-bit AES, then then, at most most, 128 bits of protection is are provided.  Implementers must ensure that
   the key-encryption algorithm is as strong or stronger than the
   content-encryption algorithm or content-authenticated-encryption
   algorithm.</t>
      <t>
   The selection of the key-derivation function imposes an upper bound
   on the strength of the resulting key-encryption key.  The strength of
   the selected key-derivation function should be at least as strong as
   the key-encryption algorithm that is selected.  NIST SP 800-56C
   Revision 1 <xref target="NIST2018"/> target="NIST2018" format="default"/> offers advice on the security strength of
   several popular key-derivation functions.</t>
      <t>
   Implementers should not mix quantum-resistant key management
   algorithms with their non-quantum-resistant counterparts.  For
   example, the same content should not be protected with
   KeyTransRecipientInfo and KeyTransPSKRecipientInfo.  Likewise, the
   same content should not be protected with KeyAgreeRecipientInfo and
   KeyAgreePSKRecipientInfo.  Doing so would make the content vulnerable
   to the future invention of a large-scale quantum computer.</t>
      <t>
   Implementers should not send the same content in different messages,
   one using a quantum-resistant key management algorithm and the other
   using a non-quantum-resistant key management algorithm, even if the
   content-encryption key is generated independently.  Doing so may
   allow an eavesdropper to correlate the messages, making the content
   vulnerable to the future invention of a large-scale quantum computer.</t>
      <t>
   This specification does not require that PSK is be known only by the
   sender and recipients.  The PSK may be known to a group.  Since
   confidentiality depends on the key transport or key agreement
   algorithm, knowledge of the PSK by other parties does not enable inherently enable
   eavesdropping.  However, group members can record the
   traffic of other members, members and then decrypt it if they ever gain
   access to a large-scale quantum computer.  Also, when many parties
   know the PSK, there are many opportunities for theft of the PSK by an
   attacker.  Once an attacker has the PSK, they can decrypt stored
   traffic if they ever gain access to a large-scale quantum computer in
   the same manner as a legitimate group member.</t>
      <t>
   Sound cryptographic key hygiene is to use a key for one and only one
   purpose.  Use of the recipient's public key for both the traditional
   CMS and the PSK-mixing variation specified in this document would be
   a violation of this principle; however, there is no known way for an
   attacker to take advantage of this situation.  That said, an
   application should enforce separation whenever possible.   For example, a purpose identifier for use in the X.509 extended key usage
 certificate extension <xref target="RFC5280"/> target="RFC5280" format="default"/> could be identified in the future to
 indicate that a public key should only be used in conjunction with a
   PSK, or only without.</t>
 without a PSK.</t>
      <t>

   Implementations must randomly generate key-derivation keys as well as
   the
   content-encryption keys or content-authenticated-encryption keys.
   Also, the generation of public/private key pairs for the key
   transport and key agreement algorithms rely on a random numbers.  The
   use of inadequate pseudo-random pseudorandom number generators (PRNGs) to generate
   cryptographic 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 brute-force searching the whole key space.
   The generation of quality random numbers is difficult.  <xref target="RFC4086"/> target="RFC4086" format="default"/>
   offers important guidance in this area.</t>
      <t>
   Implementers should be aware that cryptographic algorithms become
   weaker with time.  As new cryptanalysis techniques are developed and
   computing performance improves, the work factor to break a particular
   cryptographic algorithm will be reduced.  Therefore, 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>
      <t>
   The security properties provided by the mechanisms specified in this
   document can be validated using formal methods.  A ProVerif proof in
   <xref target="H2019"/> target="H2019" format="default"/> shows that an attacker with a large-scale quantum computer
   that is capable of breaking the Diffie-Hellman key agreement
   algorithm cannot disrupt the delivery of the content-encryption key
   to the recipient and that the attacker cannot learn the content-encryption
   key from the protocol exchange.</t>
    </section>
    <section title="Privacy Considerations" anchor="sect-8"><t> anchor="sect-8" numbered="true" toc="default">
      <name>Privacy Considerations</name>

 <t>
   An observer can see which parties are using each PSK simply by
   watching the PSK key identifiers.  However, the addition of these key identifiers is does not really making weaken
 the privacy worse. situation.  When key transport
   is used, the RecipientIdentifier is always present, and it clearly
   identifies each recipient to an observer.  When key agreement is
   used, either the IssuerAndSerialNumber or the RecipientKeyIdentifier
   is always present, and these clearly identify each recipient.</t>
    </section>
    <section title="IANA Considerations" anchor="sect-9"><t> anchor="sect-9" numbered="true" toc="default">
      <name>IANA Considerations</name>

      <t>
   One object identifier for the ASN.1 module in <xref target="sect-6"/> target="sect-6" format="default"/> was assigned
   in the SMI "SMI Security for S/MIME Module Identifiers
   (1.2.840.113549.1.9.16.0) Identifier
   (1.2.840.113549.1.9.16.0)" registry <xref target="IANA-MOD"/> registry:</t>

	<figure><artwork><![CDATA[ target="IANA" format="default"/>:</t>
      <sourcecode name="" type="asn.1"><![CDATA[
   id-mod-cms-ori-psk-2019 OBJECT IDENTIFIER ::= {
      iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) mod(0) TBD0 69 }
]]></artwork>
	</figure> ]]></sourcecode>
      <t>
   One new registry was created for Other Recipient Info Identifiers
   within entry has been added in the SMI "SMI Security for S/MIME Mail
      Security
   (1.2.840.113549.1.9.16) (1.2.840.113549.1.9.16)" registry <xref target="IANA-SMIME"/> registry:</t>

	<figure><artwork><![CDATA[ target="IANA" format="default"/>:</t>
      <sourcecode name="" type="asn.1"><![CDATA[
   id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
     rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 13 }
]]></artwork>
	</figure> ]]></sourcecode>
      <t>A new registry titled "SMI Security for S/MIME Other
      Recipient Info Identifiers (1.2.840.113549.1.9.16.13)" has been created.

      </t>

<t>
   Updates to the new registry are to be made according to the
   Specification Required policy as defined in <xref target="RFC8126"/>. target="RFC8126" format="default"/>.  The expert is expected to ensure that any new values identify additions additional
 RecipientInfo structures for use with the CMS.   Object identifiers
   for other purposes should not be assigned in this arc.</t>
      <t>
   Two assignments were made in the new SMI "SMI Security for S/MIME Other Recipient
   Info Identifiers (1.2.840.113549.1.9.16.TBD1) <xref target="IANA-ORI"/> (1.2.840.113549.1.9.16.13)" registry <xref target="IANA" format="default"/>
   with references to this document:</t>

	<figure><artwork><![CDATA[
      <sourcecode name="" type="asn.1"><![CDATA[
   id-ori-keyTransPSK OBJECT IDENTIFIER ::= {
      iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) id-ori(TBD1) id-ori(13) 1 }

   id-ori-keyAgreePSK OBJECT IDENTIFIER ::= {
      iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) id-ori(TBD1) id-ori(13) 2 }
]]></artwork>
	</figure> ]]></sourcecode>
    </section>
  </middle>
  <back>
	<references title="Normative References">
	&RFC2119;
	&RFC5083;
	&RFC5652;
	&RFC5912;
	&RFC6268;
	&RFC8126;
	&RFC8174;

<displayreference target="I-D.hoffman-c2pq" to="C2PQ"/>

    <references>
      <name>References</name>

      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5083.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

        <reference anchor="X680"><front> anchor="X680">
          <front>
            <title>Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
            <seriesInfo name="ITU-T" value="Recommendation X.680"/>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date month="August" year="2015"/>
          </front>

	<seriesInfo name="ITU-T" value="Recommendation X.680"/>
        </reference>

        <reference anchor="X690"><front> anchor="X690">
          <front>
            <title>Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <seriesInfo name="ITU-T" value="Recommendation X.690"/>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date month="August" year="2015"/>
          </front>

	<seriesInfo name="ITU-T" value="Recommendation X.690"/>
        </reference>

      </references>
	<references title="Informative References">
      <references>

        <name>Informative References</name>

        <reference anchor="AES"><front>
	<title>FIPS Pub 197: Advanced anchor="AES">
          <front>
            <title>Advanced Encryption Standard (AES)</title>
<seriesInfo name="NIST PUB" value="197"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.197"/>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date month="26" year="November 2001"/> month="November" year="2001"/>
          </front>
        </reference>

<!-- <reference anchor='C2PQ'>
<front>
<title>The Transition from Classical to Post-Quantum Cryptography</title>

<author initials='P' surname='Hoffman' fullname='Paul Hoffman'>
    <organization />
</author>

<date month='May' day='21' year='2019' />

<abstract><t>Quantum computing is the study of computers that use quantum
features in calculatio ns.  For over 20 years, it has been known that if very
large, specialized quantum computers coul d be built, they could have a
devastating effect on asymmetric classical cryptographic algorithm s such as
RSA and elliptic curve signatures and key exchange, as well as (but in smaller
scale) on symmetric cryptographic algorithms such as block ciphers, MACs, and
hash functions.  There ha s already been a great deal of study on how to
create algorithms that will resist large, special ized quantum computers, but
so far, the properties of those algorithms make them onerous to adopt before
they are needed.  Small quantum computers are being built today, but it is
still far fr om clear when large, specialized quantum computers will be built
that can recover private or sec ret keys in classical algorithms at the key
sizes commonly used today.  It is important to be ab le to predict when large,
specialized quantum computers usable for cryptanalysis will be possibl e so
that organization can change to post-quantum cryptographic algorithms well
before they are needed.  This document describes quantum computing, how it
might be used to attack classical cry ptographic algorithms, and possibly how
to predict when large, specialized quantum computers wil l become
feasible.</t></abstract>

</front>
<seriesInfo name='Work in Progress,' value='draft-hoffman-c2pq-05' />
</reference> anchor="I-D.hoffman-c2pq">; I-D Exists -->
        <xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.hoffman-c2pq.xml"/>

        <reference anchor="FGHT2016" target="https://eprint.iacr.org/2016/961.pdf"><front> target="https://eprint.iacr.org/2016/961.pdf">
          <front>
            <title>A kilobit hidden SNFS discrete logarithm computation</title>
            <seriesInfo name="Cryptology ePrint Archive Report" value="2016/961"/>
            <author fullname="J. Fried" initials="J." surname="Fried">
	</author> surname="Fried"/>
            <author fullname="P. Gaudry" initials="P." surname="Gaudry">
	</author> surname="Gaudry"/>
            <author fullname="N. Heninger" initials="N." surname="Heninger">
	</author> surname="Heninger"/>
            <author fullname="E. Thome" initials="E." surname="Thome">
	</author> surname="Thome"/>
            <date year="2016"/> year="2016" month="October"/>
          </front>

	<seriesInfo name="Cryptology" value="ePrint Archive Report 2016/961"/>
        </reference>

        <reference anchor="H2019" target="https://mailarchive.ietf.org/arch/msg/spasm/_6d_4jp3sOprAnbU2fp_yp_-6-k"><front>
	<title>Re: target="https://mailarchive.ietf.org/arch/msg/spasm/_6d_4jp3sOprAnbU2fp_yp_-6-k">
          <front>
            <title>Subject: [lamps] WG Last Call for
	    draft-ietf-lamps-cms-mix-with-psk"</title>
            <author fullname="J. Hammell" initials="J." surname="Hammell">
	</author> surname="Hammell"/>
            <date month="May" year="2019"/>
          </front>
	  <refcontent> message to the IETF mailing list</refcontent>
        </reference>

        <reference anchor="IANA-MOD" target="https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-0"><front>
	<title>IANA-MOD</title>
	<author>
	</author>

	<date/>
	</front>

	</reference>
	<reference anchor="IANA-SMIME" target="https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime"><front>
	<title>IANA-SMIME</title>
	<author>
	</author>

	<date/>
	</front>

	</reference>
	<reference anchor="IANA-ORI" target="https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-TBD1"><front>
	<title>IANA-ORI</title>
	<author>
	</author> anchor="IANA" target="https://www.iana.org/assignments/smi-numbers">
          <front>
            <title>Structure of Management Information (SMI) Numbers (MIB Module Registrations)</title>
            <author><organization>IANA</organization></author>
            <date/>
          </front>
        </reference>

        <reference anchor="NAS2019"><front> anchor="NAS2019">
          <front>
            <title>Quantum Computing: Progress and Prospects</title>
<seriesInfo name="DOI" value="10.17226/25196"/>
            <author>
              <organization>National Academies of Sciences, Engineering, and Medicine</organization>
            </author>
            <date year="2019"/>
          </front>

	<seriesInfo name="The" value="National Academies Press DOI 10.17226/25196"/>
        </reference>

        <reference anchor="NIST2018" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr1.pdf"><front> target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr1.pdf">
          <front>
            <title>Recommendation for Key-Derivation Methods in Key-Establishment Schemes</title>
            <seriesInfo name="NIST Special Publication" value="800-56C Revision 1"/>
            <author fullname="E. Barker" initials="E." surname="Barker">
	</author> surname="Barker"/>
            <author fullname="L. Chen" initials="L." surname="Chen">
	</author> surname="Chen"/>
            <author fullname="R. Davis" initials="R." surname="Davis">
	</author> surname="Davis"/>
            <date month="April" year="2018"/>
          </front>

	<seriesInfo name="NIST" value="Special Publication 800-56C Rev. 1"/>
        </reference>

        <reference anchor="S1994"><front> anchor="S1994">
          <front>
            <title>Algorithms for Quantum Computation: Discrete Logarithms and Factoring</title>
            <author fullname="P. Shor" initials="P." surname="Shor">
	</author> surname="Shor"/>
            <date year="1994"/> year="1994" month="November"/>
          </front>

	<seriesInfo name="Proceedings" value="of
            <refcontent>Proceedings of the 35th Annual Symposium on Foundations of Computer Science Science, pp. 124-134"/> 124-134"</refcontent>
        </reference>
	&RFC2631;
	&RFC4086;
	&RFC5280;
	&RFC5753;
	&RFC5869;
	&RFC8017;
	&RFC8619;

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2631.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5753.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8619.xml"/>
      </references>
    </references>

    <section title="Key anchor="sect-a" numbered="true" toc="default">
      <name>Key Transport with PSK Example" anchor="sect-a"><t> Example</name>
      <t>
   This example shows the establishment of an AES-256 content-encryption
   key using:</t>

	<t><list style="symbols" hangIndent="3">
        <t>a
      <ul spacing="normal">
        <li>a pre-shared key of 256 bits;</t>
	<t>key bits;</li>
        <li>key transport using RSA PKCS#1 v1.5 with a 3072-bit key;</t>
	<t>key key;</li>
        <li>key derivation using HKDF with SHA-384; and</t>
	<t>key and</li>
        <li>key wrap using AES-256-KEYWRAP.</t>
	</list>
	</t> AES-256-KEYWRAP.</li>
      </ul>
      <t>
   In real-world use, the originator would encrypt the key-derivation
   key in their own RSA public key as well as the recipient's public
   key.  This is omitted in an attempt to simplify the example.</t>
      <section title="Originator anchor="sect-a.1" numbered="true" toc="default">
        <name>Originator Processing Example" anchor="sect-a.1"> Example</name>
        <t> The pre-shared key known to Alice and Bob, in hexadecimal:</t>

   <figure><artwork> hexadecimal, is:</t>
        <sourcecode type="test-vectors"><![CDATA[
   c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb05213365cf95b15
   </artwork></figure> ]]></sourcecode>
        <t> The identifier assigned to the pre-shared key is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   ptf-kmc:13614122112
   </artwork></figure>  ]]></sourcecode>
        <t>Alice obtains Bob's public key:</t>

	<figure><artwork><![CDATA[
        <sourcecode type="test-vectors"><![CDATA[
   -----BEGIN PUBLIC KEY-----
   MIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEA3ocW14cxncPJ47fnEjBZ
   AyfC2lqapL3ET4jvV6C7gGeVrRQxWPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JH
   Keeza+itfuhsz3yifgeEpeK8T+SusHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqq
   vS3jg/VO+OPnZbofoHOOevt8Q/roahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx
   2AHHZJevo3nmRnlgJXo6mE00E/6qkhjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0v
   SH7qUl8/vN13y4UOFkn8hM4kmZ6bJqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39a
   uLNnH3EXdXaV1tk75H3qC7zJaeGWMJyQfOE3YfEGRKn8fxubji716D8UecAxAzFy
   FL6m1JiOyV5acAiOpxN14qRYZdHnXOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fS
   whSZG7VNf+vgNWTLNYSYLI04KiMdulnvU6ds+QPz+KKtAgMBAAE=
   -----END PUBLIC KEY-----
]]></artwork>
        </figure>  ]]></sourcecode>
        <t> Bob's RSA public key has the following key identifier: </t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   9eeb67c9b95a74d44d2f16396680e801b5cba49c
   </artwork></figure> ]]></sourcecode>
        <t> Alice randomly generates a content-encryption key: </t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   c8adc30f4a3e20ac420caa76a68f5787c02ab42afea20d19672fd963a5338e83
   </artwork></figure> ]]></sourcecode>
        <t> Alice randomly generates a key-derivation key: </t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   df85af9e3cebffde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde81eb
   </artwork></figure> ]]></sourcecode>
        <t> Alice encrypts the key-derivation key in Bob's public key: </t>

<figure><artwork><![CDATA[
   4e6200431ed95e0e28f7288dba56d4b90e75959e068884664c43368f3d978f3d
   8179e5837e3c27bf8dc1f6e2827b9ede969be77417516de07d90e37c560add01
   48deb0c9178088ccb72c068d8a9076b6a5e7ecc9093e30fdeaecc9e138d80626
   74fcf685f3082b910839551cd8741beedeee6e87c08ff84f03ba87118730cdf7
   667002316f1a29a6cc596c7ddf95a51e398927d1916bf27929945de080fc7c80
   6af6281aed6492acffa4ef1b4f53e67fca9a417db2350a2277d586ee3cabefd3
   b4a44f04d3c6803d54fe9a7159210dabedda9a94f310d303331da51c0218d92a
   2efb003792259195a9fd4cc403af613fdf1a6265ea70bf702fd1c6f734264c9a
   59196e8e8fd657fa028e272ef741eb7711fd5b3f4ea7da9c33df66bf487da710
   1c9bbfddaf1c073900a3ea99da513d8aa32605db07dc1c47504cab30c9304a85
   d87377f603ec3df4056ddcf3d756fb7ed98254421a4ae151f17ad4e28c5ea077
   63358dfb1ef5f73435f337b21a38c1a3fa697a530dd97e462f6b5fb2052a2d53
]]></artwork>
        </figure>
        <sourcecode type="test-vectors"><![CDATA[
   52693f12140c91dea2b44c0b7936f6be46de8a7bfab072bcb6ecfd56b06a9f65
   1bd4669d336aef7b449e5cd9b151893b7c7a3b8e364394840b0a5434cbf10e1b
   5670aefd074faf380665d204fb95153543346f36c2125dba6f4d23d2bc61434b
   5e36ff72b3eafe57c6cf7f74924c309f174b0b8753554b58ed33a8848d707a98
   c0c2b1ddcfd09e31fe213ca0a48dd157bd7d842e85cc76f77710d58efeaa0525
   c651bcd1410fb47534ecabaf5ab7daabed809d4b97220caf6d4929c5fb684f7b
   b8692e6e70332ff9b3f7c11d6cac51d4a35593173d48f80ca843b89789d625e7
   997ad7d674d25a2a7d165a5f39b3cb6358e937bdb02ac8a524ac93113cedd9ad
   c68263025c0bb0997d716e58d4d7b69739bf591f3e71c7678dc0df96f3df9e8a
   a5738f4f9ce21489f300e040891b20b2ab6d9051b3c2e68efa2fa9799a706878
   d5f462018c021d6669ed649f9acdf78476810198bfb8bd41ffedc585eafa957e
   ea1d3625e4bed376e7ae49718aee2f575c401a26a29941d8da5b7ee9aca36471 ]]></sourcecode>
        <t> Alice produces a 256-bit key-encryption key with HKDF using
	SHA-384; the secret value is the key-derivation key; and the 'info' is the DER-
encoded DER-encoded CMSORIforPSKOtherInfo structure with the following values: </t>

	<figure><artwork><![CDATA[
        <sourcecode type="test-vectors"><![CDATA[
 0   56: SEQUENCE {
 2   32:   OCTET STRING
       :     C2 44 CD D1 1A 0D 1F 39 D9 B6 12 82 77 02 44 FB
       :     0F 6B EF B9 1A B7 F9 6C B0 52 13 36 5C F9 5B 15
36    1:   ENUMERATED 5
39   11:   SEQUENCE {
41    9:     OBJECT IDENTIFIER aes256-wrap
          :       { 2 (2 16 840 1 101 3 4 1 45 } 45)
       :     }
52    1:   INTEGER 32
55    1:   INTEGER 32
       :   }

]]></artwork>
	</figure> ]]></sourcecode>
        <t> The DER encoding of CMSORIforPSKOtherInfo produces 58 octets:</t>
   <figure><artwork>
        <sourcecode type="test-vectors">
<![CDATA[   30380420c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb0521336
   5cf95b150a0105300b060960864801650304012d020120020120
   </artwork></figure> ]]></sourcecode>
        <t>The HKDF output is 256 bits:</t>
   <figure><artwork>
   a14d87451dfd11d83cd54ffe2bd38c49a2adfed3ac49f1d3e62bbdc64ae43b32
   </artwork></figure>
        <sourcecode type="test-vectors">
<![CDATA[  f319e9cebb35f1c6a7a9709b8760b9d0d3e30e16c5b2b69347e9f00ca540a232 ]]></sourcecode>
        <t> Alice uses AES-KEY-WRAP to encrypt the 256-bit content-encryption key with the key-encryption key:</t>
   <figure><artwork>
   ae4ea1d99e78fcdcea12d9f10d991ac71502939ee0c30ebdcc97dd1fc5ba3566
   c83d0dd5d1b4faa5
   </artwork></figure>
        <sourcecode type="test-vectors">
<![CDATA[   ea0947250fa66cd525595e52a69aaade88efcf1b0f108abe291060391b1cdf59
   07f36b4067e45342 ]]></sourcecode>
        <t>Alice encrypts the content using AES-256-GCM with the content-encryption key.  The 12-octet nonce used is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors">
<![CDATA[   cafebabefacedbaddecaf888
   </artwork></figure> ]]></sourcecode>
        <t>The content plaintext is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors">
<![CDATA[   48656c6c6f2c20776f726c6421
   </artwork></figure> ]]></sourcecode>
        <t>The resulting ciphertext is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors">
<![CDATA[   9af2d16f21547fcefed9b3ef2d
   </artwork></figure> ]]></sourcecode>
        <t>The resulting 12-octet authentication tag is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors">
<![CDATA[   a0e5925cc184e0172463c44c
   </artwork></figure> ]]></sourcecode>
      </section>
      <section title="ContentInfo anchor="sect-a.2" numbered="true" toc="default">
        <name>ContentInfo and AuthEnvelopedData" anchor="sect-a.2"><t> AuthEnvelopedData</name>
        <t>
   Alice encodes the AuthEnvelopedData and the ContentInfo, ContentInfo and
   sends the result to Bob.  The resulting structure is:</t>

	<figure><artwork><![CDATA[
        <sourcecode type="test-vectors"><![CDATA[
     0  650: SEQUENCE {
     4   11:  OBJECT IDENTIFIER authEnvelopedData
           :   { 1   authEnvelopedData (1 2 840 113549 1 9 16 1 23 } 23)
    17  633:  [0] {
    21  629:   SEQUENCE {
    25    1:    INTEGER 0
    28  551:    SET {
    32  547:     [4] {
    36   11:      OBJECT IDENTIFIER ** Placeholder **
           :       { 1       keyTransPSK (1 2 840 113549 1 9 16 TBD 1 } 13 1)
    49  530:      SEQUENCE {
    53    1:       INTEGER 0
    56   19:       OCTET STRING 'ptf-kmc:13614122112'
    77   13:       SEQUENCE {
    79   11:        OBJECT IDENTIFIER ** Placeholder **
           :         { 1         hkdf-with-sha384 (1 2 840 113549 1 9 16 3 TBD } 29)
           :         }
    92   11:       SEQUENCE {
    94    9:        OBJECT IDENTIFIER aes256-wrap
           :         { 2         aes256-wrap (2 16 840 1 101 3 4 1 45 } 45)
           :         }
   105  432:       SEQUENCE {
   109  428:        SEQUENCE {
   113    1:         INTEGER 2
   116   20:         [0]
           :          9E EB 67 C9 B9 5A 74 D4 4D 2F 16 39 66 80 E8 01
           :          B5 CB A4 9C
   138   13:         SEQUENCE {
   140    9:          OBJECT IDENTIFIER rsaEncryption
           :           { 1           rsaEncryption (1 2 840 113549 1 1 1 } 1)
   151    0:          NULL
           :          }
   153  384:         OCTET STRING
           :          18 09 D6 23 17 DF 2D 09 55 57 3B FE 75 95 EB 6A
           :          3D 57 84 6C          52 69 C1 49 0B F1 11 1A BB 40 3F 12 14 0C D8 B5 91 DE A2 B4 4C 0B 79 36 F6 BE
           :          26 5F D3 62 4B E2 D8 E4 CA          46 DE 8A 7B FA B0 72 BC B6 EC FD 56 B0 6A 12 36 CA 38 E3 9F 65
           :          A0 7D AA E0 5F A1 E3 BC 59 F3 AD A8 8D 95 A1 6B          1B D4 66 9D 33 6A EF 7B 44 9E 5C D9 B1 51 89 3B
           :          06 85 20 93 C7 C5 C0 05 62 ED DF 02 1D FE 68          7C
           :          18 A1 3A AB AA 59 92 30 6A 7A 3B 8E 36 43 94 84 0B 0A 54 34 CB F1 0E 1B 92 73 D5 01 C6 5B
           :          56 70 AE FD 1E BB A9 B9 D2 7F 48 49 7F 3C 07 4F 3C 13 E3 2B AF 38 06 65 D2 04 FB 95 15 35
           :          2A 19 F1 7A CD          43 34 6F 36 C2 12 5D BA 6F 4D 23 D2 BC 56 28 EF 7F CA 4F 69 6B 7E 92 61 43 4B
           :          66 22 0D 13 B7 23 AD 41 9E          5E 98 2A 80 B7 6C 77
           : 36 FF 9B 76 B1 04 BA 30 6D 4B 4D F9 25 72 B3 EA FE 57 E0 C6 CF 7F 0E
           :          95 9A 43 6D 14 D5 72 3F AA 8F 66 35 40 D0 E3 71 74 92 4C 30 9F
           :          17 4B 7F 20 9D 0B 87 53 55 4B 58 ED 67 EA 33 79 CD AB A8 84 16 72 07 D2
           :          AC 8D 3A DA 12 43 B7 2F 3A 70 7A 98
           :          C0 C2 B1 DD CF 91 3E F1 D9 58 20 D0 9E 31 FE 21 3C A0 A4 8D D1 57
           :          6D F2 9C 09 E1 EC D2 0B 82 BE 5D 69          BD 7D 84 2E 85 CC 76 F7 77 6F 10 D5 8E FE F7 AA 05 25
           :          EB F6 31 C0 D9          C6 51 BC D1 41 0F B4 75 34 EC AB AF 5A B7 15 BF D0 24 F3 05 1F FF 48 76 DA AB
           :          ED 80 9D 4B 97 22 0C AF 6D 49 29 C5 FB 68 4F 7B
           :          B8 69 2E 6E 70 33 2F F9 B3 F7 C1 1D 73 6C AC 51 D4
           :          A3 55 93 17 19 2C 38 C6 D5 86 BD 67 82 2D B2 61 AA 3D 48 F8 0C A8 43 B8 97 89 D6 25 E7
           :          08 C7 E4          99 7A D7 D6 74 D2 5A 2A 7D 16 5A 5F 39 B3 CB 63
           :          58 E9 37 34 D1 2D E0 51 32 15 4A BD B0 2A C8 A5 24 AC 6B 2B 28 93 11 3C ED D9 AD
           :          5B CD FA 7C 65 89 2F A2          C6 82 63 DB AB 64 88 43 CC 66 02 5C 0B B0 99 7D 71 6E 58 D4 D7 B6 97
           :          27 84 29 AC 15 5F 3B 9E 5B          39 BF 59 1F 3E 71 C7 67 8D C0 DF 99 AE 96 F3 DF 9E 8A
           :          A5 73 8F 4F 9C E2 14 89 F3 00 E0 40 89 1B 20 B2 BC
           :          19 6C 17 A1 99 A5 CF F7 80 32 11 88 F1 9D          AB 6D 90 51 B3 6F C2 E6 8E FA 2F A9 79 9A 70 68 78
           :          4B 16 5F 3F 03 F7 D2 04 3D DE 5F 30          D5 F4 62 01 8C 02 1D 66 69 ED 64 9F 9A CD 8B BB 3A
           :          38 DA 9D EC 16 6C 36 4F 8B 7E 99 AA 99 FB 42 D6 F7 84
           :          1A          76 81 01 98 BF B8 BD 41 FF 3C ED C5 85 D7 A2 30 74 2C D3 AA F7 18 2A EA FA 95 7E
           :          EA 1D 36 25 3C E4 BE D3 76 E7 AE 49 71 8A EE 2F 57
           :          B5 02 C4 17 62 21 97 F1 E9 81 83 D0 4E BF          5C 40 1A 26 A2 99 41 D8 DA 5B 5D 7E E9 AC A3 64 71
           :          }
           :         }
   541   40:       OCTET STRING
           :        AE 4E A1 D9 9E 78 FC DC        EA 12 D9 F1 0D 99 1A C7 09 47 25 0F A6 6C D5 25 59 5E 52 A6 9A AA DE
           :        15 02 93 9E E0 C3 0E BD CC 97 DD 1F C5 BA 35 66        88 EF CF 1B 0F 10 8A BE 29 10 60 39 1B 1C DF 59
           :        C8 3D 0D D5 D1 B4 FA A5        07 F3 6B 40 67 E4 53 42
           :        }
           :       }
           :      }
   583   55:    SEQUENCE {
   585    9:     OBJECT IDENTIFIER data { 1 (1 2 840 113549 1 7 1 } 1)
   596   27:     SEQUENCE {
   598    9:      OBJECT IDENTIFIER aes256-GCM
           :       { 2       aes256-GCM (2 16 840 1 101 3 4 1 46 } 46)
   609   14:      SEQUENCE {
   611   12:       OCTET STRING
           :        CA FE BA BE FA CE DB AD DE CA F8 88
           :        }
           :       }
   625   13:     [0]
           :      9A F2 D1 6F 21 54 7F CE FE D9 B3 EF 2D
           :      }
   640   12:    OCTET STRING A0 E5 92 5C C1 84 E0 17 24 63 C4 4C
           :    }
           :   }
           :  }
]]></artwork>
	</figure> ]]></sourcecode>
      </section>
      <section title="Recipient anchor="sect-a.3" numbered="true" toc="default">
        <name>Recipient Processing Example" anchor="sect-a.3"> Example</name>
        <t>Bob's private key:</t>

<figure><artwork><![CDATA[ key is:</t>
        <sourcecode type="test-vectors"><![CDATA[
   -----BEGIN RSA PRIVATE KEY-----
   MIIG5AIBAAKCAYEA3ocW14cxncPJ47fnEjBZAyfC2lqapL3ET4jvV6C7gGeVrRQx
   WPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JHKeeza+itfuhsz3yifgeEpeK8T+Su
   sHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqqvS3jg/VO+OPnZbofoHOOevt8Q/ro
   ahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx2AHHZJevo3nmRnlgJXo6mE00E/6q
   khjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0vSH7qUl8/vN13y4UOFkn8hM4kmZ6b
   JqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39auLNnH3EXdXaV1tk75H3qC7zJaeGW
   MJyQfOE3YfEGRKn8fxubji716D8UecAxAzFyFL6m1JiOyV5acAiOpxN14qRYZdHn
   XOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fSwhSZG7VNf+vgNWTLNYSYLI04KiMd
   ulnvU6ds+QPz+KKtAgMBAAECggGATFfkSkUjjJCjLvDk4aScpSx6+Rakf2hrdS3x
   jwqhyUfAXgTTeUQQBs1HVtHCgxQd+qlXYn3/qu8TeZVwG4NPztyi/Z5yB1wOGJEV
   3k8N/ytul6pJFFn6p48VM01bUdTrkMJbXERe6g/rr6dBQeeItCaOK7N5SIJH3Oqh
   9xYuB5tH4rquCdYLmt17Tx8CaVqU9qPY3vOdQEOwIjjMV8uQUR8rHSO9KkSj8AGs
   Lq9kcuPpvgJc2oqMRcNePS2WVh8xPFktRLLRazgLP8STHAtjT6SlJ2UzkUqfDHGK
   q/BoXxBDu6L1VDwdnIS5HXtL54ElcXWsoOyKF8/ilmhRUIUWRZFmlS1ok8IC5IgX
   UdL9rJVZFTRLyAwmcCEvRM1asbBrhyEyshSOuN5nHJi2WVJ+wSHijeKl1qeLlpMk
   HrdIYBq4Nz7/zXmiQphpAy+yQeanhP8O4O6C8e7RwKdpxe44su4Z8fEgA5yQx0u7
   8yR1EhGKydX5bhBLR5Cm1VM7rT2BAoHBAP/+e5gZLNf/ECtEBZjeiJ0VshszOoUq
   haUQPA+9Bx9pytsoKm5oQhB7QDaxAvrn8/FUW2aAkaXsaj9F+/q30AYSQtExai9J
   fdKKook3oimN8/yNRsKmhfjGOj8hd4+GjX0qoMSBCEVdT+bAjjry8wgQrqReuZnu
   oXU85dmb3jvv0uIczIKvTIeyjXE5afjQIJLmZFXsBm09BG87Ia5EFUKly96BOMJh
   /QWEzuYYXDqOFfzQtkAefXNFW21Kz4Hw2QKBwQDeiGh4lxCGTjECvG7fauMGlu+q
   DSdYyMHif6t6mx57eS16EjvOrlXKItYhIyzW8Kw0rf/CSB2j8ig1GkMLTOgrGIJ1
   0322o50FOr5oOmZPueeR4pOyAP0fgQ8DD1L3JBpY68/8MhYbsizVrR+Ar4jM0f96
   W2bF5Xj3h+fQTDMkx6VrCCQ6miRmBUzH+ZPs5n/lYOzAYrqiKOanaiHy4mjRvlsy
   mjZ6z5CG8sISqcLQ/k3Qli5pOY/v0rdBjgwAW/UCgcEAqGVYGjKdXCzuDvf9EpV4
   mpTWB6yIV2ckaPOn/tZi5BgsmEPwvZYZt0vMbu28Px7sSpkqUuBKbzJ4pcy8uC3I
   SuYiTAhMiHS4rxIBX3BYXSuDD2RD4vG1+XM0h6jVRHXHh0nOXdVfgnmigPGz3jVJ
   B8oph/jD8O2YCk4YCTDOXPEi8Rjusxzro+whvRR+kG0gsGGcKSVNCPj1fNISEte4
   gJId7O1mUAAzeDjn/VaS/PXQovEMolssPPKn9NocbKbpAoHBAJnFHJunl22W/lrr
   ppmPnIzjI30YVcYOA5vlqLKyGaAsnfYqP1WUNgfVhq2jRsrHx9cnHQI9Hu442PvI
   x+c5H30YFJ4ipE3eRRRmAUi4ghY5WgD+1hw8fqyUW7E7l5LbSbGEUVXtrkU5G64T
   UR91LEyMF8OPATdiV/KD4PWYkgaqRm3tVEuCVACDTQkqNsOOi3YPQcm270w6gxfQ
   SOEy/kdhCFexJFA8uZvmh6Cp2crczxyBilR/yCxqKOONqlFdOQKBwFbJk5eHPjJz
   AYueKMQESPGYCrwIqxgZGCxaqeVArHvKsEDx5whI6JWoFYVkFA8F0MyhukoEb/2x
   2qB5T88Dg3EbqjTiLg3qxrWJ2OxtUo8pBP2I2wbl2NOwzcbrlYhzEZ8bJyxZu5i1
   sYILC8PJ4Qzw6jS4Qpm4y1WHz8e/ElW6VyfmljZYA7f9WMntdfeQVqCVzNTvKn6f
   hg6GSpJTzp4LV3ougi9nQuWXZF2wInsXkLYpsiMbL6Fz34RwohJtYA==
   -----END RSA PRIVATE KEY-----
]]></artwork>
	</figure> ]]></sourcecode>
        <t> Bob decrypts the key-derivation key with his RSA private key:</t>
   <figure><artwork>
        <sourcecode type="test-vectors">
   <![CDATA[   df85af9e3cebffde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde81eb
   </artwork></figure> ]]></sourcecode>
        <t>Bob produces a 256-bit key-encryption key with HKDF using SHA-384;
	the secret value is the key-derivation key; and the 'info' is
	the DER-encoded CMSORIforPSKOtherInfo structure with the same
	values as shown in A.1. <xref target="sect-a.1"/>. The HKDF output is 256 bits:</t>
   <figure><artwork>
   a14d87451dfd11d83cd54ffe2bd38c49a2adfed3ac49f1d3e62bbdc64ae43b32
   </artwork></figure>
        <sourcecode type="test-vectors"><![CDATA[
   f319e9cebb35f1c6a7a9709b8760b9d0d3e30e16c5b2b69347e9f00ca540a232 ]]></sourcecode>
        <t>Bob uses AES-KEY-WRAP to decrypt the content-encryption key with the key-encryption key; the content-encryption key is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   c8adc30f4a3e20ac420caa76a68f5787c02ab42afea20d19672fd963a5338e83
   </artwork></figure> ]]></sourcecode>
        <t>Bob decrypts the content using AES-256-GCM with the content-encryption key, key and checks the received authentication tag. The 12-octet nonce used is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors">
   <![CDATA[   cafebabefacedbaddecaf888
   </artwork></figure>  ]]></sourcecode>
        <t>The 12-octet authentication tag is: </t>
   <figure><artwork>
        <sourcecode type="test-vectors">
   <![CDATA[   a0e5925cc184e0172463c44c
   </artwork></figure> ]]></sourcecode>
        <t>The received ciphertext content is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors">
   <![CDATA[   9af2d16f21547fcefed9b3ef2d
   </artwork></figure>  ]]></sourcecode>
        <t>The resulting plaintext content is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors">
   <![CDATA[   48656c6c6f2c20776f726c6421
   </artwork></figure> ]]></sourcecode>
      </section>
    </section>
    <section title="Key anchor="sect-b" numbered="true" toc="default">
      <name>Key Agreement with PSK Example" anchor="sect-b"><t> Example</name>
      <t>
   This example shows the establishment of an AES-256 content-encryption
   key using:</t>

	<t><list style="symbols" hangIndent="3">
        <t>a
      <ul spacing="normal">
        <li>a pre-shared key of 256 bits;</t>
	<t>key bits;</li>

        <li>key agreement using ECDH on curve P-384 and X9.63 KDF
        with SHA-384;</t>
	<t>key SHA-384;</li>
        <li>key derivation using HKDF with SHA-384; and</t>
	<t>key and</li>
        <li>key wrap using AES-256-KEYWRAP.</t>
	</list>
	</t> AES-256-KEYWRAP.</li>
      </ul>
      <t>
   In real-world use, the originator would treat themselves as an
   additional recipient by performing key agreement with their own
   static public key and the ephemeral private key generated for this
   message.  This is omitted in an attempt to simplify the example.</t>
      <section title="Originator anchor="sect-b.1" numbered="true" toc="default">
        <name>Originator Processing Example" anchor="sect-b.1"> Example</name>
        <t> The pre-shared key known to Alice and Bob, in hexadecimal:</t>
   <figure><artwork> hexadecimal, is:</t>
        <sourcecode type="test-vectors"><![CDATA[
   4aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c078660214e2d83e4
   </artwork></figure> ]]></sourcecode>
        <t>The identifier assigned to the pre-shared key is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   ptf-kmc:216840110121
   </artwork></figure>   ]]></sourcecode>
        <t>Alice randomly generates a content-encryption key:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033
   </artwork></figure> ]]></sourcecode>
        <t>Alice obtains Bob's static ECDH public key:</t>

	<figure><artwork><![CDATA[
        <sourcecode type="test-vectors"><![CDATA[
   -----BEGIN PUBLIC KEY-----
   MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEScGPBO9nmUwGrgbGEoFY9HR/bCo0WyeY
   /dePQVrwZmwN2yMJmO2d1kWCvLTz8U7atinxyIRe9CV54yau1KWU/wbkhPDnzuSM
   YkcpxMGo32z3JetEloW5aFOja13vv/W5
   -----END PUBLIC KEY-----
]]></artwork>
	</figure> ]]></sourcecode>
        <t>It has a key identifier of:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   e8218b98b8b7d86b5e9ebdc8aeb8c4ecdc05c529
   </artwork></figure>  ]]></sourcecode>
        <t> Alice generates an ephemeral ECDH key pair on the same curve:</t>

	<figure><artwork><![CDATA[
        <sourcecode type="test-vectors"><![CDATA[
   -----BEGIN EC PRIVATE KEY-----
   MIGkAgEBBDCMiWLG44ik+L8cYVvJrQdLcFA+PwlgRF+Wt1Ab25qUh8OB7OePWjxp
   /b8P6IOuI6GgBwYFK4EEACKhZANiAAQ5G0EmJk/2ks8sXY1kzbuG3Uu3ttWwQRXA
   LFDJICjvYfr+yTpOQVkchm88FAh9MEkw4NKctokKNgpsqXyrT3DtOg76oIYENpPb
   GE5lJdjPx9sBsZQdABwlsU0Zb7P/7i8=
   -----END EC PRIVATE KEY-----
]]></artwork>
	</figure> ]]></sourcecode>
        <t>Alice computes a shared secret, secret called Z, "Z" using the Bob's static ECDH
   public key and her ephemeral ECDH private key; Z is: </t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   3f015ed0ff4b99523a95157bbe77e9cc0ee52fcffeb7e41eac79d1c11b6cc556
   19cf8807e6d800c2de40240fe0e26adc
   </artwork></figure>   ]]></sourcecode>
        <t> Alice computes the pairwise key-encryption key, called KEK1, "KEK1", from Z using
the X9.63 KDF with the ECC-CMS-SharedInfo structure with the following values:
</t>

	<figure><artwork><![CDATA[
        <sourcecode type="test-vectors"><![CDATA[
 0   21: SEQUENCE {
 2   11:   SEQUENCE {
 4    9:     OBJECT IDENTIFIER aes256-wrap
          :       { 2 (2 16 840 1 101 3 4 1 45 } 45)
       :     }
15    6:   [2] {
17    4:     OCTET STRING 00 00 00 20
       :     }
       :   }
]]></artwork>
	</figure> ]]></sourcecode>
        <t>The DER encoding of ECC-CMS-SharedInfo produces 23 octets:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   3015300b060960864801650304012da206040400000020
   </artwork></figure>  ]]></sourcecode>
        <t>The X9.63 KDF output is the 256-bit KEK1:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   27dc25ddb0b425f7a968ceada80a8f73c6ccaab115baafcce4a22a45d6b8f3da
   </artwork></figure>  ]]></sourcecode>
        <t>Alice produces the 256-bit KEK2 with HKDF using SHA-384; the secret
value is KEK1; and the 'info' is the DER-encoded CMSORIforPSKOtherInfo
structure with the following values:</t>

	<figure><artwork><![CDATA[
        <sourcecode type="test-vectors"><![CDATA[
 0   56: SEQUENCE {
 2   32:   OCTET STRING
       :     4A A5 3C BF 50 08 50 DD 58 3A 5D 98 21 60 5C 6F
       :     A2 28 FB 59 17 F8 7C 1C 07 86 60 21 4E 2D 83 E4
36    1:   ENUMERATED 10
39   11:   SEQUENCE {
41    9:     OBJECT IDENTIFIER aes256-wrap
          :       { 2 (2 16 840 1 101 3 4 1 45 } 45)
       :      }
52    1:   INTEGER 32
55    1:   INTEGER 32
       :   }
]]></artwork>
	</figure> ]]></sourcecode>
        <t>The DER encoding of CMSORIforPSKOtherInfo produces 58 octets:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   303804204aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c07866021
   4e2d83e40a010a300b060960864801650304012d020120020120
   </artwork></figure>  ]]></sourcecode>
        <t>The HKDF output is the 256-bit KEK2:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   7de693ee30ae22b5f8f6cd026c2164103f4e1430f1ab135dc1fb98954f9830bb
   </artwork></figure>  ]]></sourcecode>
        <t>Alice uses AES-KEY-WRAP to encrypt the content-encryption key with the KEK2; the wrapped key is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   229fe0b45e40003e7d8244ec1b7e7ffb2c8dca16c36f5737222553a71263a92b
   de08866a602d63f4
   </artwork></figure>  ]]></sourcecode>
        <t>Alice encrypts the content using AES-256-GCM with the content-encryption key.  The 12-octet nonce used is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   dbaddecaf888cafebabeface
   </artwork></figure> ]]></sourcecode>
        <t>The plaintext is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   48656c6c6f2c20776f726c6421
   </artwork></figure>  ]]></sourcecode>
        <t>The resulting ciphertext is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   fc6d6f823e3ed2d209d0c6ffcf
   </artwork></figure>  ]]></sourcecode>
        <t>The resulting 12-octet authentication tag is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   550260c42e5b29719426c1ff
   </artwork></figure> ]]></sourcecode>
      </section>
      <section title="ContentInfo anchor="sect-b.2" numbered="true" toc="default">
        <name>ContentInfo and AuthEnvelopedData" anchor="sect-b.2"><t> AuthEnvelopedData</name>
        <t>
   Alice encodes the AuthEnvelopedData and the ContentInfo, ContentInfo and
   sends the result to Bob.  The resulting structure is:</t>

	<figure><artwork><![CDATA[
        <sourcecode type="test-vectors"><![CDATA[
     0  327: SEQUENCE {
     4   11:  OBJECT IDENTIFIER authEnvelopedData
           :   { 1   authEnvelopedData (1 2 840 113549 1 9 16 1 23 } 23)
    17  310:  [0] {
    21  306:   SEQUENCE {
    25    1:    INTEGER 0
    28  229:    SET {
    31  226:     [4] {
    34   11:      OBJECT IDENTIFIER ** Placeholder **
           :       { 1       keyAgreePSK (1 2 840 113549 1 9 16 TBD 2 } 13 2)
    47  210:      SEQUENCE {
    50    1:       INTEGER 0
    53   20:       OCTET STRING 'ptf-kmc:216840110121'
    75   85:       [0] {
    77   83:        [1] {
    79   19:         SEQUENCE {
    81    6:          OBJECT IDENTIFIER
           :           dhSinglePass-stdDH-sha256kdf-scheme
           :           { 1           ecdhX963KDF-SHA256 (1 3 132 1 11 1 } 1)
    89    9:          OBJECT IDENTIFIER aes256-wrap
           :           { 2           aes256-wrap (2 16 840 1 101 3 4 1 45 } 45)
           :           }
   100   60:         BIT STRING, encapsulates {
   103   57:          OCTET STRING
           :          1B 41 26 26 4F F6 92 CF 2C 5D 8D 64 CD BB 86 DD
           :          4B B7 B6 D5 B0 41 15 C0 2C 50 C9 20 28 EF 61 FA
           :          FE C9 3A 4E 41 59 1C 86 6F 3C 14 08 7D 30 49 30
           :          E0 D2 9C B6 89 0A 36 0A 6C
           :          }
           :         }
           :        }
   162   13:       SEQUENCE {
   164   11:        OBJECT IDENTIFIER ** Placeholder **
           :         { 1         hkdf-with-sha384 (1 2 840 113549 1 9 16 3 TBD } 29)
           :         }
   177   11:       SEQUENCE {
   179    9:        OBJECT IDENTIFIER aes256-wrap
           :         { 2         aes256-wrap (2 16 840 1 101 3 4 1 45 } 45)
           :         }
   190   68:       SEQUENCE {
   192   66:        SEQUENCE {
   194   22:         [0] {
   196   20:          OCTET STRING
           :          E8 21 8B 98 B8 B7 D8 6B 5E 9E BD C8 AE B8 C4 EC
           :          DC 05 C5 29
           :          }
   218   40:         OCTET STRING
           :         22 9F E0 B4 5E 40 00 3E 7D 82 44 EC 1B 7E 7F FB
           :         2C 8D CA 16 C3 6F 57 37 22 25 53 A7 12 63 A9 2B
           :         DE 08 86 6A 60 2D 63 F4
           :         }
           :        }
           :       }
           :      }
           :     }
   260   55:    SEQUENCE {
   262    9:     OBJECT IDENTIFIER data { 1 (1 2 840 113549 1 7 1 } 1)
   273   27:     SEQUENCE {
   275    9:      OBJECT IDENTIFIER aes256-GCM
           :       { 2       aes256-GCM (2 16 840 1 101 3 4 1 46 } 46)
   286   14:      SEQUENCE {
   288   12:       OCTET STRING
           :        DB AD DE CA F8 88 CA FE BA BE FA CE
           :        }
           :       }
   302   13:     [0]
           :      FC 6D 6F 82 3E 3E D2 D2 09 D0 C6 FF CF
           :      }
   317   12:    OCTET STRING 55 02 60 C4 2E 5B 29 71 94 26 C1 FF
           :     }
           :    }
           :   }
]]></artwork>
	</figure> ]]></sourcecode>
      </section>

      <section title="Recipient anchor="sect-b.3" numbered="true" toc="default">
        <name>Recipient Processing Example" anchor="sect-b.3"> Example</name>
        <t> Bob obtains Alice's ephemeral ECDH public key from the message:</t>

<figure><artwork><![CDATA[
        <sourcecode type="test-vectors"><![CDATA[
   -----BEGIN PUBLIC KEY-----
   MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEORtBJiZP9pLPLF2NZM27ht1Lt7bVsEEV
   wCxQySAo72H6/sk6TkFZHIZvPBQIfTBJMODSnLaJCjYKbKl8q09w7ToO+qCGBDaT
   2xhOZSXYz8fbAbGUHQAcJbFNGW+z/+4v
   -----END PUBLIC KEY-----
]]></artwork>
	</figure> ]]></sourcecode>
        <t> Bob's static ECDH private key:</t>
   <figure><artwork><![CDATA[ key is:</t>
        <sourcecode type="test-vectors"><![CDATA[
   -----BEGIN EC PRIVATE KEY-----
   MIGkAgEBBDAnJ4hB+tTUN9X03/W0RsrYy+qcptlRSYkhaDIsQYPXfTU0ugjJEmRk
   NTPj4y1IRjegBwYFK4EEACKhZANiAARJwY8E72eZTAauBsYSgVj0dH9sKjRbJ5j9
   149BWvBmbA3bIwmY7Z3WRYK8tPPxTtq2KfHIhF70JXnjJq7UpZT/BuSE8OfO5Ixi
   RynEwajfbPcl60SWhbloU6NrXe+/9bk=
   -----END EC PRIVATE KEY-----
   ]]></artwork>
	</figure>   ]]></sourcecode>
        <t> Bob computes a shared secret, secret called Z, "Z" using the Alice's ephemeral
   ECDH public key and his static ECDH private key; Z is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   3f015ed0ff4b99523a95157bbe77e9cc0ee52fcffeb7e41eac79d1c11b6cc556
   19cf8807e6d800c2de40240fe0e26adc
    </artwork></figure>  ]]></sourcecode>
        <t> Bob computes the pairwise key-encryption key, called KEK1, from Z using
   the X9.63 KDF with the ECC-CMS-SharedInfo structure with the values shown
   in B.1. <xref target="sect-b.1"/>.  The X9.63 KDF output is the 256-bit KEK1:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   27dc25ddb0b425f7a968ceada80a8f73c6ccaab115baafcce4a22a45d6b8f3da
   </artwork></figure>   ]]></sourcecode>
        <t>Bob produces the 256-bit KEK2 with HKDF using SHA-384; the secret	value
   is KEK1; and the 'info' is the DER-encoded CMSORIforPSKOtherInfo structure with
   the values shown in B.1. <xref target="sect-b.1"/>.  The HKDF output is the 256-bit KEK2:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   7de693ee30ae22b5f8f6cd026c2164103f4e1430f1ab135dc1fb98954f9830bb
   </artwork></figure> ]]></sourcecode>
        <t> Bob uses AES-KEY-WRAP to decrypt the content-encryption key with the
   KEK2; the content-encryption key is: </t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033
   </artwork></figure>   ]]></sourcecode>
        <t>Bob decrypts the content using AES-256-GCM with the content-encryption
   key,
   key and checks the received authentication tag.  The 12-octet nonce used is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   dbaddecaf888cafebabeface
   </artwork></figure>   ]]></sourcecode>
        <t>The 12-octet authentication tag is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   550260c42e5b29719426c1ff
   </artwork></figure>   ]]></sourcecode>
        <t>The received ciphertext content is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   fc6d6f823e3ed2d209d0c6ffcf
   </artwork></figure>   ]]></sourcecode>
        <t>The resulting plaintext content is:</t>
   <figure><artwork>
        <sourcecode type="test-vectors"><![CDATA[
   48656c6c6f2c20776f726c6421
   </artwork></figure>   ]]></sourcecode>
      </section>
    </section>
    <section title="Acknowledgements" numbered="no" anchor="acknowledgements"><t> numbered="false" anchor="acknowledgements" toc="default">
      <name>Acknowledgements</name>
      <t>
   Many thanks to Roman Danyliw, Ben Kaduk, Burt Kaliski, Panos
   Kampanakis, Jim Schaad, Robert Sparks, Sean Turner, and Daniel Van
   Geest for their review and insightful comments.  They have greatly
   improved the design, clarity, and implementation guidance.</t>
    </section>
  </back>

</rfc>