rfc8696xml2.original.xml   rfc8696.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC5083 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5083.xml">
<!ENTITY RFC5652 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5652.xml">
<!ENTITY RFC5912 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5912.xml">
<!ENTITY RFC6268 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6268.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8126.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC2631 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2631.xml">
<!ENTITY RFC4086 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4086.xml">
<!ENTITY RFC5280 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5280.xml">
<!ENTITY RFC5753 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5753.xml">
<!ENTITY RFC5869 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5869.xml">
<!ENTITY RFC8017 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8017.xml">
<!ENTITY RFC8619 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8619.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-lamps-cms-mix-with-psk-07" catego
ry="std" ipr="trust200902">
<!-- 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) in the Crypto">Using Pre-Shared
Key (PSK) in the Cryptographic Message Syntax (CMS)</title>
<author fullname="Russ Housley" initials="R." surname="Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address><postal><street>516 Dranesville Road</street>
<street>Herndon, VA 20170</street>
<street>USA</street>
</postal>
<email>housley@vigilsec.com</email>
</address>
</author>
<date month="October" year="2019"/> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<abstract><t>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
docName="draft-ietf-lamps-cms-mix-with-psk-07" number="8696" category="std"
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 -->
<front>
<title abbrev="Using PSK in the CMS">Using Pre-Shared Key (PSK) in the Crypt
ographic 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 Dranesville Road</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="December" year="2019"/>
<abstract>
<t>
The invention of a large-scale quantum computer would pose a serious The invention of a large-scale quantum computer would pose a serious
challenge for the cryptographic algorithms that are widely deployed challenge for the cryptographic algorithms that are widely deployed
today. The Cryptographic Message Syntax (CMS) supports key transport today. The Cryptographic Message Syntax (CMS) supports key transport
and key agreement algorithms that could be broken by the invention of and key agreement algorithms that could be broken by the invention of
such a quantum computer. By storing communications that are such a quantum computer. By storing communications that are
protected with the CMS today, someone could decrypt them in the protected with the CMS today, someone could decrypt them in the
future when a large-scale quantum computer becomes available. Once future when a large-scale quantum computer becomes available. Once
quantum-secure key management algorithms are available, the CMS will quantum-secure key management algorithms are available, the CMS will
be extended to support the new algorithms, if the existing syntax be extended to support the new algorithms if the existing syntax
does not accommodate them. In the near-term, this document describes does not accommodate them. This document describes
a mechanism to protect today's communication from the future a mechanism to protect today's communication from the future
invention of a large-scale quantum computer by mixing the output of invention of a large-scale quantum computer by mixing the output of
key transport and key agreement algorithms with a pre-shared key.</t> key transport and key agreement algorithms with a pre-shared key.</t>
</abstract>
</abstract> </front>
</front> <middle>
<section anchor="sect-1" numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction" anchor="sect-1"><t> <t>
The invention of a large-scale quantum computer would pose a serious The invention of a large-scale quantum computer would pose a serious
challenge for the cryptographic algorithms that are widely deployed challenge for the cryptographic algorithms that are widely deployed
today <xref target="S1994"/>. It is an open question whether or not it is fe today <xref target="S1994" format="default"/>. It is an open question whethe
asible r or not it is feasible
to build a large-scale quantum computer, and if so, when that might to build a large-scale quantum computer and, if so, when that might
happen <xref target="NAS2019"/>. However, if such a quantum computer is inve happen <xref target="NAS2019" format="default"/>. However, if such a quantum
nted, computer is invented,
many of the cryptographic algorithms and the security protocols that many of the cryptographic algorithms and the security protocols that
use them would become vulnerable.</t> use them would become vulnerable.</t>
<t>
<t> The Cryptographic Message Syntax (CMS) <xref target="RFC5652" format="default
The Cryptographic Message Syntax (CMS) <xref target="RFC5652"/><xref target=" "/><xref target="RFC5083" format="default"/> supports
RFC5083"/> supports
key transport and key agreement algorithms that could be broken by key transport and key agreement algorithms that could be broken by
the invention of a large-scale quantum computer <xref target="C2PQ"/>. These the invention of a large-scale quantum computer <xref target="I-D.hoffman-c2p
algorithms include RSA <xref target="RFC8017"/>, Diffie-Hellman <xref target= q" format="default"/>. These
"RFC2631"/>, and algorithms include RSA <xref target="RFC8017" format="default"/>, Diffie-Hell
Elliptic Curve Diffie-Hellman <xref target="RFC5753"/>. As a result, an adve man <xref target="RFC2631" format="default"/>, and
rsary Elliptic Curve Diffie-Hellman (ECDH) <xref target="RFC5753" format="default"/
that stores CMS-protected communications today, could decrypt those >. As a result, an adversary
that stores CMS-protected communications today could decrypt those
communications in the future when a large-scale quantum computer communications in the future when a large-scale quantum computer
becomes available.</t> becomes available.</t>
<t>
<t>
Once quantum-secure key management algorithms are available, the CMS Once quantum-secure key management algorithms are available, the CMS
will be extended to support them, if the existing syntax does not will be extended to support them if the existing syntax does not
already accommodate the new algorithms.</t> already accommodate the new algorithms.</t>
<t> <t>
In the near-term, this document describes a mechanism to protect In the near term, this document describes a mechanism to protect
today's communication from the future invention of a large-scale today's communication from the future invention of a large-scale
quantum computer by mixing the output of existing key transport and quantum computer by mixing the output of existing key transport and
key agreement algorithms with a pre-shared key (PSK). Secure key agreement algorithms with a pre-shared key (PSK). Secure
communication can be achieved today by mixing a strong PSK with the communication can be achieved today by mixing a strong PSK with the
output of an existing key transport algorithm, like RSA <xref target="RFC8017 output of an existing key transport algorithm, like RSA <xref target="RFC8017
"/>, or " format="default"/>, or
an existing key agreement algorithm, like Diffie-Hellman <xref target="RFC263 an existing key agreement algorithm, like Diffie-Hellman <xref target="RFC263
1"/> or 1" format="default"/> or
Elliptic Curve Diffie-Hellman <xref target="RFC5753"/>. A security solution Elliptic Curve Diffie-Hellman (ECDH) <xref target="RFC5753" format="default"/
that is >. A
security solution that is
believed to be quantum resistant can be achieved by using a PSK with believed to be quantum resistant can be achieved by using a PSK with
sufficient entropy along with a quantum resistant key derivation sufficient entropy along with a quantum-resistant key derivation
function (KDF), like HKDF <xref target="RFC5869"/>, and a quantum resistant function (KDF), like an HMAC-based key derivation function
encryption algorithm, like 256-bit AES <xref target="AES"/>. In this way, to (HKDF) <xref target="RFC5869" format="default"/>, and a quantum-resistant
day's encryption algorithm, like 256-bit AES <xref target="AES" format="default"/>.
In this way, today's
CMS-protected communication can be resistant to an attacker with a CMS-protected communication can be resistant to an attacker with a
large-scale quantum computer.</t> large-scale quantum computer.</t>
<t>
<t>
In addition, there may be other reasons for including a strong PSK In addition, there may be other reasons for including a strong PSK
besides protection against the future invention of a large-scale besides protection against the future invention of a large-scale
quantum computer. For example, there is always the possibility of a quantum computer. For example, there is always the possibility of a
cryptoanalytic breakthrough on one or more of the classic public-key cryptoanalytic breakthrough on one or more classic public key
algorithm, and there are longstanding concerns about undisclosed algorithms, and there are longstanding concerns about undisclosed
trapdoors in Diffie-Hellman parameters <xref target="FGHT2016"/>. Inclusion trapdoors in Diffie-Hellman parameters <xref target="FGHT2016" format="defaul
of a t"/>. Inclusion of a
strong PSK as part of the overall key management offer additional strong PSK as part of the overall key management offers additional
protection against these concerns.</t> protection against these concerns.</t>
<t>
<t>
Note that the CMS also supports key management techniques based on Note that the CMS also supports key management techniques based on
symmetric key-encryption keys and passwords, but they are not symmetric key-encryption keys and passwords, but they are not
discussed in this document because they are already quantum discussed in this document because they are already quantum
resistant. The symmetric key-encryption key technique is quantum resistant. The symmetric key-encryption key technique is quantum
resistant when used with an adequate key size. The password resistant when used with an adequate key size. The password
technique is quantum resistant when used with a quantum-resistant key technique is quantum resistant when used with a quantum-resistant key
derivation function and a sufficiently large password.</t> derivation function and a sufficiently large password.</t>
<section anchor="sect-1.1" numbered="true" toc="default">
<section title="Terminology" anchor="sect-1.1"><t> <name>Terminology</name>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
they appear in all RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
</section> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
<section title="ASN.1" anchor="sect-1.2"><t> </t>
CMS values are generated using ASN.1 <xref target="X680"/>, which uses the Ba </section>
sic <section anchor="sect-1.2" numbered="true" toc="default">
<name>ASN.1</name>
<t>
CMS values are generated using ASN.1 <xref target="X680" format="default"/>,
which uses the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER) Encoding Rules (BER) and the Distinguished Encoding Rules (DER)
<xref target="X690"/>.</t> <xref target="X690" format="default"/>.</t>
</section>
</section> <section anchor="sect-1.3" numbered="true" toc="default">
<name>Version Numbers</name>
<section title="Version Numbers" anchor="sect-1.3"><t> <t>
The major data structures include a version number as the first item 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 in the data structure. The version number is intended to avoid ASN.1
decode errors. Some implementations do not check the version number decode errors. Some implementations do not check the version number
prior to attempting a decode, and then if a decode error occurs, the prior to attempting a decode; then, if a decode error occurs, the
version number is checked as part of the error handling routine. version number is checked as part of the error-handling routine.
This is a reasonable approach; it places error processing outside of This is a reasonable approach; it places error processing outside of
the fast path. This approach is also forgiving when an incorrect the fast path. This approach is also forgiving when an incorrect
version number is used by the sender.</t> version number is used by the sender.</t>
<t>
<t>
Whenever the structure is updated, a higher version number will be Whenever the structure is updated, a higher version number will be
assigned. However, to ensure maximum interoperability, the higher assigned. However, to ensure maximum interoperability, the higher
version number is only used when the new syntax feature is employed. version number is only used when the new syntax feature is employed.
That is, the lowest version number that supports the generated syntax That is, the lowest version number that supports the generated syntax
is used.</t> is used.</t>
</section>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default">
</section> <name>Overview</name>
<t>
<section title="Overview" anchor="sect-2"><t> The CMS enveloped-data content type <xref target="RFC5652" format="default"/>
The CMS enveloped-data content type <xref target="RFC5652"/> and the CMS and the CMS
authenticated-enveloped-data content type <xref target="RFC5083"/> support bo authenticated-enveloped-data content type <xref target="RFC5083" format="defa
th key ult"/> support both key
transport and key agreement public-key algorithms to establish the transport and key agreement public key algorithms to establish the
key used to encrypt the content. No restrictions are imposed on the key used to encrypt the content. No restrictions are imposed on the
key transport or key agreement public-key algorithms, which means key transport or key agreement public key algorithms, which means
that any key transport or key agreement algorithm can be used, that any key transport or key agreement algorithm can be used,
including algorithms that are specified in the future. In both including algorithms that are specified in the future. In both
cases, the sender randomly generates the content-encryption key, and cases, the sender randomly generates the content-encryption key, and
then all recipients obtain that key. All recipients use the sender- then all recipients obtain that key. All recipients use the sender-generated
generated symmetric content-encryption key for decryption.</t> symmetric content-encryption key for decryption.</t>
<t>
<t>
This specification defines two quantum-resistant ways to establish a This specification defines two quantum-resistant ways to establish a
symmetric key-encryption key, which is used to encrypt the sender- symmetric key-encryption key, which is used to encrypt the sender-generated c
generated content-encryption key. In both cases, the PSK is used as ontent-encryption key. In both cases, the PSK is used as
one of the inputs to a key-derivation function to create a quantum- one of the inputs to a key-derivation function to create a quantum-resistant
resistant key-encryption key. The PSK MUST be distributed to the key-encryption key. The PSK <bcp14>MUST</bcp14> be distributed to the
sender and all of the recipients by some out-of-band means that does 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 not make it vulnerable to the future invention of a large-scale
quantum computer, and an identifier MUST be assigned to the PSK. It quantum computer, and an identifier <bcp14>MUST</bcp14> be assigned to the PS K. It
is best if each PSK has a unique identifier; however, if a recipient 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 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 each of them in turn. A PSK is expected to be used with many
messages, with a lifetime of weeks or months.</t> messages, with a lifetime of weeks or months.</t>
<t>
<t>
The content-encryption key or content-authenticated-encryption key is The content-encryption key or content-authenticated-encryption key is
quantum-resistant, and the sender establishes it using these steps:</t> quantum resistant, and the sender establishes it using these steps:</t>
<t><list style="hanging" hangIndent="3"> <t>When using a key transport algorithm:</t>
<t hangText="When using a key transport algorithm:">
<list style="numbers"> <ol spacing="normal" type="1">
<t>The content-encryption key or the content-authenticated-
encryption key, called CEK, is generated at random.</t>
<t>The key-derivation key, called KDK, is generated at random.</t>
<t>For each recipient, the KDK is encrypted in the recipient's
public key, then the key derivation function (KDF) is used to
mix the pre-shared key (PSK) and the KDK to produce the key-
encryption key, called KEK.</t>
<t>The KEK is used to encrypt the CEK.</t>
</list>
</t>
<t hangText="When using a key agreement algorithm:"> <li>The content-encryption key or the
content-authenticated-encryption key, called "CEK", is generated at r
andom.</li>
<li>The key-derivation key, called "KDK", is generated at random.</l
i>
<li>For each recipient, the KDK is encrypted in the recipient's
public key, then the KDF is used to
mix the PSK and the KDK to produce the
key-encryption key, called "KEK".</li>
<li>The KEK is used to encrypt the CEK.</li>
</ol>
<list style="numbers"> <t>When using a key agreement algorithm:</t>
<t>The content-encryption key or the content-authenticated-
encryption key, called CEK, is generated at random.</t>
<t>For each recipient, a pairwise key-encryption key, called 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 each recipient, the key derivation function (KDF) is used
to mix the pre-shared key (PSK) and the pairwise KEK1, and the
result is called KEK2.</t>
<t>For each recipient, the pairwise KEK2 is used to encrypt the
CEK.</t>
</list>
</t>
</list> <ol spacing="normal" type="1">
</t> <li>The content-encryption key or the
content-authenticated-encryption key, called "CEK", is generated at r
andom.</li>
<li>For each recipient, a pairwise key-encryption key,
called "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 k
ey.</li>
<li>For each recipient, the KDF is used
to mix the PSK and the pairwise KEK1, and the
result is called "KEK2".</li>
<li>For each recipient, the pairwise KEK2 is used to encrypt the
CEK.</li>
</ol>
<t> <t>
As specified in Section 6.2.5 of <xref target="RFC5652"/>, recipient informat As specified in <xref target="RFC5652" sectionFormat="of" section="6.2.5"/>,
ion for recipient information for
additional key management techniques are represented in the additional key management techniques is represented in the
OtherRecipientInfo type. Two key management techniques are specified OtherRecipientInfo type. Two key management techniques are specified
in this document, and they are each identified by a unique ASN.1 in this document, and they are each identified by a unique ASN.1
object identifier.</t> object identifier.</t>
<t>
<t> The first key management technique, called "keyTransPSK" (see
The first key management technique, called keyTransPSK, see <xref target="sect-3" format="default"/>), uses a key transport algorithm to
<xref target="sect-3"/>, uses a key transport algorithm to transfer the key- transfer the key-derivation key from the sender to the recipient, and then the k
derivation key from the sender to the recipient, and then the key- ey-derivation key is mixed with the PSK using a KDF. The output of the
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 KDF is the key-encryption key, which is used for the encryption of
the content-encryption key or content-authenticated-encryption key.</t> the content-encryption key or content-authenticated-encryption key.</t>
<t>
<t> The second key management technique, called "keyAgreePSK" (see
The second key management technique, called keyAgreePSK, see <xref target="sect-4" format="default"/>), uses a key agreement algorithm to
<xref target="sect-4"/>, uses a key agreement algorithm to establish a pairwi establish a pairwise key-encryption
se key. This pairwise key-encryption key is then mixed with the PSK using a
key-encryption key, which is then mixed with the PSK using a KDF to KDF to produce a second pairwise key-encryption key, which is then used to
produce a second pairwise key-encryption key, which is then used to encrypt the content-encryption key or content-authenticated-encryption key.</t>
encrypt the content-encryption key or content-authenticated- </section>
encryption key.</t> <section anchor="sect-3" numbered="true" toc="default">
<name>keyTransPSK</name>
</section> <t>
<section title="keyTransPSK" anchor="sect-3"><t>
Per-recipient information using keyTransPSK is represented in the Per-recipient information using keyTransPSK is represented in the
KeyTransPSKRecipientInfo type, which is indicated by the id-ori- KeyTransPSKRecipientInfo type, which is indicated by the id-ori-keyTransPSK o
keyTransPSK object identifier. Each instance of bject identifier. Each instance of
KeyTransPSKRecipientInfo establishes the content-encryption key or KeyTransPSKRecipientInfo establishes the content-encryption key or
content-authenticated-encryption key for one or more recipients that content-authenticated-encryption key for one or more recipients that
have access to the same PSK.</t> have access to the same PSK.</t>
<t>The id-ori-keyTransPSK object identifier is:</t>
<t>The id-ori-keyTransPSK object identifier is:</t> <sourcecode name="" type="asn.1"><![CDATA[
<figure><artwork><![CDATA[
id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 }
id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 }
]]></artwork>
</figure>
<t>The KeyTransPSKRecipientInfo type is:</t>
<figure><artwork><![CDATA[ id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } ]]></sourcecode>
<t>The KeyTransPSKRecipientInfo type is:</t>
<sourcecode name="" type="asn.1"><![CDATA[
KeyTransPSKRecipientInfo ::= SEQUENCE { KeyTransPSKRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 version CMSVersion, -- always set to 0
pskid PreSharedKeyIdentifier, pskid PreSharedKeyIdentifier,
kdfAlgorithm KeyDerivationAlgorithmIdentifier, kdfAlgorithm KeyDerivationAlgorithmIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
ktris KeyTransRecipientInfos, ktris KeyTransRecipientInfos,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
PreSharedKeyIdentifier ::= OCTET STRING PreSharedKeyIdentifier ::= OCTET STRING
KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo ]]></sourcecode>
]]></artwork> <t>The fields of the KeyTransPSKRecipientInfo type have the following
</figure>
<t>The fields of the KeyTransPSKRecipientInfo type have the following
meanings:</t> meanings:</t>
<t><list hangIndent="3" style="hanging"><t> <ul>
version is the syntax version number. The version MUST be 0. The <li>
CMSVersion type is described in Section 10.2.5 of <xref target="RFC5652"/> version is the syntax version number. The version <bcp14>MUST</bcp14> be
.</t> 0. The
CMSVersion type is described in <xref target="RFC5652"
</list> sectionFormat="of" section="10.2.5"/>.</li>
</t> <li>
<t><list hangIndent="3" style="hanging"><t>
pskid is the identifier of the PSK used by the sender. The 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> identifier is an OCTET STRING, and it need not be human readable.</li>
<li>
</list> kdfAlgorithm identifies the key-derivation algorithm and any associated pa
</t> rameters used by the sender to mix the key-derivation key and the PSK to generat
e the key-encryption key.
<t><list hangIndent="3" style="hanging"><t> The KeyDerivationAlgorithmIdentifier is described in <xref target="RFC5652
kdfAlgorithm identifies the key-derivation algorithm, and any " sectionFormat="of" section="10.1.6"/>.</li>
associated parameters, used by the sender to mix the key- <li>
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>
keyEncryptionAlgorithm identifies a key-encryption algorithm used keyEncryptionAlgorithm identifies a key-encryption algorithm used
to encrypt the content-encryption key. The to encrypt the content-encryption key. The
KeyEncryptionAlgorithmIdentifier is described in Section 10.1.3 of KeyEncryptionAlgorithmIdentifier is described in <xref target="RFC5652" se
<xref target="RFC5652"/>.</t> ctionFormat="of" section="10.1.3"/>.</li>
<li>
</list>
</t>
<t><list hangIndent="3" style="hanging"><t>
ktris contains one KeyTransRecipientInfo type for each recipient; ktris contains one KeyTransRecipientInfo type for each recipient;
it uses a key transport algorithm to establish the key-derivation it uses a key transport algorithm to establish the key-derivation
key. That is, the encryptedKey field of KeyTransRecipientInfo key. That is, the encryptedKey field of KeyTransRecipientInfo
contains the key-derivation key instead of the content-encryption contains the key-derivation key instead of the content-encryption
key. KeyTransRecipientInfo is described in Section 6.2.1 of key. KeyTransRecipientInfo is described in <xref target="RFC5652" section
<xref target="RFC5652"/>.</t> Format="of" section="6.2.1"/>.</li>
<li>
</list>
</t>
<t><list hangIndent="3" style="hanging"><t>
encryptedKey is the result of encrypting the content-encryption encryptedKey is the result of encrypting the content-encryption
key or the content-authenticated-encryption key with the key- key or the content-authenticated-encryption key with the key-encryption ke
encryption key. EncryptedKey is an OCTET STRING.</t> y. EncryptedKey is an OCTET STRING.</li>
</ul>
</list> </section>
</t> <section anchor="sect-4" numbered="true" toc="default">
<name>keyAgreePSK</name>
</section> <t>
<section title="keyAgreePSK" anchor="sect-4"><t>
Per-recipient information using keyAgreePSK is represented in the Per-recipient information using keyAgreePSK is represented in the
KeyAgreePSKRecipientInfo type, which is indicated by the id-ori- KeyAgreePSKRecipientInfo type, which is indicated by the id-ori-keyAgreePSK o
keyAgreePSK object identifier. Each instance of bject identifier. Each instance of
KeyAgreePSKRecipientInfo establishes the content-encryption key or KeyAgreePSKRecipientInfo establishes the content-encryption key or
content-authenticated-encryption key for one or more recipients that content-authenticated-encryption key for one or more recipients that
have access to the same PSK.</t> have access to the same PSK.</t>
<t>The id-ori-keyAgreePSK object identifier is:</t>
<t>The id-ori-keyAgreePSK object identifier is:</t> <sourcecode name="" type="asn.1"><![CDATA[
<figure><artwork><![CDATA[
id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 }
The KeyAgreePSKRecipientInfo type is: The KeyAgreePSKRecipientInfo type is:
KeyAgreePSKRecipientInfo ::= SEQUENCE { KeyAgreePSKRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 version CMSVersion, -- always set to 0
pskid PreSharedKeyIdentifier, pskid PreSharedKeyIdentifier,
originator [0] EXPLICIT OriginatorIdentifierOrKey, originator [0] EXPLICIT OriginatorIdentifierOrKey,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
kdfAlgorithm KeyDerivationAlgorithmIdentifier, kdfAlgorithm KeyDerivationAlgorithmIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys RecipientEncryptedKeys } recipientEncryptedKeys RecipientEncryptedKeys } ]]></sourcecode>
]]></artwork> <t>
</figure>
<t>
The fields of the KeyAgreePSKRecipientInfo type have the following meanings:< /t> The fields of the KeyAgreePSKRecipientInfo type have the following meanings:< /t>
<ul>
<t><list hangIndent="3" style="hanging"><t> <li>
version is the syntax version number. The version MUST be 0. The version is the syntax version number. The version <bcp14>MUST</bcp14> be
CMSVersion type is described in Section 10.2.5 of <xref target="RFC5652"/> 0. The
.</t> CMSVersion type is described in <xref target="RFC5652"
format="default" section="10.2.5" sectionFormat="of"/>.</li>
</list> <li>
</t>
<t><list hangIndent="3" style="hanging"><t>
pskid is the identifier of the PSK used by the sender. The 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> identifier is an OCTET STRING, and it need not be human readable.</li>
<li>
</list>
</t>
<t><list hangIndent="3" style="hanging"><t>
originator is a CHOICE with three alternatives specifying the originator is a CHOICE with three alternatives specifying the
sender's key agreement public key. Implementations MUST support sender's key agreement public key. Implementations <bcp14>MUST</bcp14> su pport
all three alternatives for specifying the sender's public key. all three alternatives for specifying the sender's public key.
The sender uses their own private key and the recipient's public The sender uses their own private key and the recipient's public
key to generate a pairwise key-encryption key. A key derivation key to generate a pairwise key-encryption key. A KDF
function (KDF) is used to mix the PSK and the pairwise key- is used to mix the PSK and the pairwise key-encryption key to produce a se
encryption key to produce a second key-encryption key. The cond key-encryption key. The
OriginatorIdentifierOrKey type is described in Section 6.2.2 of OriginatorIdentifierOrKey type is described in <xref target="RFC5652" sect
<xref target="RFC5652"/>.</t> ionFormat="of" section="6.2.2"/>.</li>
<li>
</list>
</t>
<t><list hangIndent="3" style="hanging"><t>
ukm is optional. With some key agreement algorithms, the sender ukm is optional. With some key agreement algorithms, the sender
provides a User Keying Material (UKM) to ensure that a different provides a User Keying Material (UKM) to ensure that a different
key is generated each time the same two parties generate a key is generated each time the same two parties generate a
pairwise key. Implementations MUST accept a pairwise key. Implementations <bcp14>MUST</bcp14> accept a
KeyAgreePSKRecipientInfo SEQUENCE that includes a ukm field. KeyAgreePSKRecipientInfo SEQUENCE that includes a ukm field.
Implementations that do not support key agreement algorithms that Implementations that do not support key agreement algorithms that
make use of UKMs MUST gracefully handle the presence of UKMs. The make use of UKMs <bcp14>MUST</bcp14> gracefully handle the presence of UKM
UserKeyingMaterial type is described in Section 10.2.6 of s. The
<xref target="RFC5652"/>.</t> UserKeyingMaterial type is described in <xref target="RFC5652" sectionForm
at="of" section="10.2.6" />.</li>
</list> <li>
</t> kdfAlgorithm identifies the key-derivation algorithm and any
associated parameters used by the sender to mix the pairwise key-encryptio
<t><list hangIndent="3" style="hanging"><t> n key and the PSK to produce a second key-encryption key
kdfAlgorithm identifies the key-derivation algorithm, and any
associated parameters, used by the sender to mix the pairwise key-
encryption key and the PSK to produce a second key-encryption key
of the same length as the first one. The of the same length as the first one. The
KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of KeyDerivationAlgorithmIdentifier is described in <xref target="RFC5652" se
<xref target="RFC5652"/>.</t> ctionFormat="of" section="10.1.6"/>.</li>
<li>
</list>
</t>
<t><list hangIndent="3" style="hanging"><t>
keyEncryptionAlgorithm identifies a key-encryption algorithm used keyEncryptionAlgorithm identifies a key-encryption algorithm used
to encrypt the content-encryption key or the content- to encrypt the content-encryption key or the content-authenticated-encrypt
authenticated-encryption key. The ion key. The
KeyEncryptionAlgorithmIdentifier type is described in Section KeyEncryptionAlgorithmIdentifier type is described in <xref target="RFC565
10.1.3 of <xref target="RFC5652"/>.</t> 2" sectionFormat="of" section="10.1.3"/>.</li>
<li>
</list>
</t>
<t><list hangIndent="3" style="hanging"><t>
recipientEncryptedKeys includes a recipient identifier and recipientEncryptedKeys includes a recipient identifier and
encrypted key for one or more recipients. The encrypted key for one or more recipients. The
KeyAgreeRecipientIdentifier is a CHOICE with two alternatives KeyAgreeRecipientIdentifier is a CHOICE with two alternatives
specifying the recipient's certificate, and thereby the specifying the recipient's certificate, and thereby the
recipient's public key, that was used by the sender to generate a recipient's public key, that was used by the sender to generate a
pairwise key-encryption key. The encryptedKey is the result of pairwise key-encryption key. The encryptedKey is the result of
encrypting the content-encryption key or the content- encrypting the content-encryption key or the content-authenticated-encrypt
authenticated-encryption key with the second pairwise key- ion key with the second pairwise key-encryption key. EncryptedKey is an OCTET S
encryption key. EncryptedKey is an OCTET STRING. The TRING. The
RecipientEncryptedKeys type is defined in Section 6.2.2 of RecipientEncryptedKeys type is defined in <xref target="RFC5652" sectionFo
<xref target="RFC5652"/>.</t> rmat="of" section="6.2.2" />.</li>
</ul>
</list> </section>
</t> <section anchor="sect-5" numbered="true" toc="default">
<name>Key Derivation</name>
</section> <t>
Many KDFs internally employ a one-way hash
<section title="Key Derivation" anchor="sect-5"><t>
Many key derivation functions (KDFs) internally employ a one-way hash
function. When this is the case, the hash function that is used is function. When this is the case, the hash function that is used is
indirectly indicated by the KeyDerivationAlgorithmIdentifier. HKDF indirectly indicated by the KeyDerivationAlgorithmIdentifier. HKDF
<xref target="RFC5869"/> is one example of a KDF that makes use of a hash fun <xref target="RFC5869" format="default"/> is one example of a KDF that makes
ction.</t> use of a hash function.</t>
<t>
<t>
Other KDFs internally employ an encryption algorithm. When this is Other KDFs internally employ an encryption algorithm. When this is
the case, the encryption that is used is indirectly indicated by the the case, the encryption that is used is indirectly indicated by the
KeyDerivationAlgorithmIdentifier. For example, AES-128-CMAC can be KeyDerivationAlgorithmIdentifier. For example, AES-128-CMAC can be
used for randomness extraction in a KDF as described in <xref target="NIST201 used for randomness extraction in a KDF as described in <xref target="NIST201
8"/>.</t> 8" format="default"/>.</t>
<t>
<t>
A KDF has several input values. This section describes the A KDF has several input values. This section describes the
conventions for using the KDF to compute the key-encryption key for conventions for using the KDF to compute the key-encryption key for
KeyTransPSKRecipientInfo and KeyAgreePSKRecipientInfo. For KeyTransPSKRecipientInfo and KeyAgreePSKRecipientInfo. For
simplicity, the terminology used in the HKDF <xref target="RFC5869"/> specifi simplicity, the terminology used in the HKDF specification <xref target="RFC5
cation 869" format="default"/> is used here.</t>
is used here.</t>
<t>The KDF inputs are:</t> <t>The KDF inputs are:</t>
<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.
For KeyAgreePSKRecipientInfo, it is the pairwise
key-encryption key produced by the key agreement algorithm.</li>
<t> <list style="hanging" hangIndent="3"> <li> salt is an optional non-secret random value. Many KDFs do not
<t>IKM is the input keying material; it is the symmetric secret input
to the KDF. For KeyTransPSKRecipientInfo, it is the 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> salt is an optional non-secret random value. Many KDFs do not
require a salt, and the KeyDerivationAlgorithmIdentifier require a salt, and the KeyDerivationAlgorithmIdentifier
assignments for HKDF <xref target="RFC8619"/> do not offer a parameter for a assignments for HKDF <xref target="RFC8619" format="default"/> do not offe r a parameter for a
salt. If a particular KDF requires a salt, then the salt value is salt. If a particular KDF requires a salt, then the salt value is
provided as a parameter of the KeyDerivationAlgorithmIdentifier.</t> provided as a parameter of the KeyDerivationAlgorithmIdentifier.</li>
</list>
</t>
<t> <list style="hanging" hangIndent="3"> <li>L is the length of output keying material in octets; the value
<t>L is the length of output keying material in octets; the value
depends on the key-encryption algorithm that will be used. The depends on the key-encryption algorithm that will be used. The
algorithm is identified by the KeyEncryptionAlgorithmIdentifier. algorithm is identified by the KeyEncryptionAlgorithmIdentifier.
In addition, the OBJECT IDENTIFIER portion of the In addition, the OBJECT IDENTIFIER portion of the
KeyEncryptionAlgorithmIdentifier is included in the next input KeyEncryptionAlgorithmIdentifier is included in the next input
value, called info.</t> value, called "info".</li>
</list>
</t>
<t> <list style="hanging" hangIndent="3"> <li>info is optional context and application specific information.
<t>info is optional context and application specific information. The DER encoding of CMSORIforPSKOtherInfo is used as the info
The DER-encoding of CMSORIforPSKOtherInfo is used as the info
value, and the PSK is included in this structure. Note that value, and the PSK is included in this structure. Note that
EXPLICIT tagging is used in the ASN.1 module that defines this EXPLICIT tagging is used in the ASN.1 module that defines this
structure. For KeyTransPSKRecipientInfo, the ENUMERATED value of structure. For KeyTransPSKRecipientInfo, the ENUMERATED value of
5 is used. For KeyAgreePSKRecipientInfo, the ENUMERATED value of 5 is used. For KeyAgreePSKRecipientInfo, the ENUMERATED value of
10 is used. CMSORIforPSKOtherInfo is defined by the following 10 is used. CMSORIforPSKOtherInfo is defined by the following
ASN.1 structure: </t> ASN.1 structure: </li>
</list> </ul>
</t> <sourcecode name="" type="asn.1"><![CDATA[
<figure><artwork><![CDATA[
CMSORIforPSKOtherInfo ::= SEQUENCE { CMSORIforPSKOtherInfo ::= SEQUENCE {
psk OCTET STRING, psk OCTET STRING,
keyMgmtAlgType ENUMERATED { keyMgmtAlgType ENUMERATED {
keyTrans (5), keyTrans (5),
keyAgree (10) }, keyAgree (10) },
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
pskLength INTEGER (1..MAX), pskLength INTEGER (1..MAX),
kdkLength INTEGER (1..MAX) } kdkLength INTEGER (1..MAX) } ]]></sourcecode>
]]></artwork> <t>The fields of type CMSORIforPSKOtherInfo have the following
</figure> meanings:</t>
<ul>
<t>The fields of type CMSORIforPSKOtherInfo have the following meanings:</t> <li>
psk is an OCTET STRING; it contains the PSK.</li>
<t><list hangIndent="3" style="hanging"><t> <li>
psk is an OCTET STRING; it contains the PSK.</t>
</list>
</t>
<t><list hangIndent="3" style="hanging"><t>
keyMgmtAlgType is either set to 5 or 10. For keyMgmtAlgType is either set to 5 or 10. For
KeyTransPSKRecipientInfo, the ENUMERATED value of 5 is used. For KeyTransPSKRecipientInfo, the ENUMERATED value of 5 is used. For
KeyAgreePSKRecipientInfo, the ENUMERATED value of 10 is used.</t> KeyAgreePSKRecipientInfo, the ENUMERATED value of 10 is used.</li>
</list> <li>
</t>
<t><list hangIndent="3" style="hanging"><t>
keyEncryptionAlgorithm is the KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm is the KeyEncryptionAlgorithmIdentifier,
which identifies the algorithm and provides algorithm parameters, which identifies the algorithm and provides algorithm parameters,
if any.</t> if any.</li>
</list> <li>
</t>
<t><list hangIndent="3" style="hanging"><t>
pskLength is a positive integer; it contains the length of the PSK pskLength is a positive integer; it contains the length of the PSK
in octets.</t> in octets.</li>
</list> <li>
</t>
<t><list hangIndent="3" style="hanging"><t>
kdkLength is a positive integer; it contains the length of the kdkLength is a positive integer; it contains the length of the
key-derivation key in octets. For KeyTransPSKRecipientInfo, the key-derivation key in octets. For KeyTransPSKRecipientInfo, the
key-derivation key is generated by the sender. For key-derivation key is generated by the sender. For
KeyAgreePSKRecipientInfo, the key-derivation key is the pairwise KeyAgreePSKRecipientInfo, the key-derivation key is the pairwise
key-encryption key produced by the key agreement algorithm.</t> key-encryption key produced by the key agreement algorithm.</li>
</list> </ul>
</t>
<t>The KDF output is:</t> <t>The KDF output is:</t>
<ul>
<t><list hangIndent="3" style="hanging"><t> <li>
OKM is the output keying material, which is exactly L octets. The 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- OKM is the key-encryption key that is used to encrypt the content-encrypti
encryption key or the content-authenticated-encryption key.</t> on key or the content-authenticated-encryption key.</li>
</list> </ul>
</t> <t>
An acceptable KDF <bcp14>MUST</bcp14> accept IKM, L, and info inputs; an acce
<t> ptable
An acceptable KDF MUST accept IKM, L, and info inputs; and acceptable KDF <bcp14>MAY</bcp14> also accept salt and other inputs. All of these input
KDF MAY also accept salt and other inputs. All of these inputs MUST s <bcp14>MUST</bcp14>
influence the output of the KDF. If the KDF requires a salt or other influence the output of the KDF. If the KDF requires a salt or other
inputs, then those inputs MUST be provided as parameters of the inputs, then those inputs <bcp14>MUST</bcp14> be provided as parameters of th e
KeyDerivationAlgorithmIdentifier.</t> KeyDerivationAlgorithmIdentifier.</t>
</section>
</section> <section anchor="sect-6" numbered="true" toc="default">
<name>ASN.1 Module</name>
<section title="ASN.1 Module" anchor="sect-6"><t> <t>
This section contains the ASN.1 module for the two key management This section contains the ASN.1 module for the two key management
techniques defined in this document. This module imports types from techniques defined in this document. This module imports types from
other ASN.1 modules that are defined in <xref target="RFC5912"/> and <xref ta other ASN.1 modules that are defined in <xref target="RFC5912" format="defaul
rget="RFC6268"/>.</t> t"/> and <xref target="RFC6268" format="default"/>.</t>
<sourcecode name="" type="asn.1" markers="true"><![CDATA[
<figure><artwork><![CDATA[
<CODE BEGINS>
CMSORIforPSK-2019 CMSORIforPSK-2019
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { 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) } smime(16) modules(0) id-mod-cms-ori-psk-2019(69) }
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- EXPORTS All
IMPORTS IMPORTS
AlgorithmIdentifier{}, KEY-DERIVATION AlgorithmIdentifier{}, KEY-DERIVATION
FROM AlgorithmInformation-2009 -- [RFC5912] FROM AlgorithmInformation-2009 -- [RFC5912]
skipping to change at line 621 skipping to change at line 483
... } ... }
-- --
-- Key Transport with Pre-Shared Key -- Key Transport with Pre-Shared Key
-- --
ori-keyTransPSK OTHER-RECIPIENT ::= { ori-keyTransPSK OTHER-RECIPIENT ::= {
KeyTransPSKRecipientInfo IDENTIFIED BY id-ori-keyTransPSK } KeyTransPSKRecipientInfo IDENTIFIED BY id-ori-keyTransPSK }
id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 }
id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 }
KeyTransPSKRecipientInfo ::= SEQUENCE { KeyTransPSKRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 version CMSVersion, -- always set to 0
pskid PreSharedKeyIdentifier, pskid PreSharedKeyIdentifier,
kdfAlgorithm KeyDerivationAlgorithmIdentifier, kdfAlgorithm KeyDerivationAlgorithmIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
ktris KeyTransRecipientInfos, ktris KeyTransRecipientInfos,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
skipping to change at line 668 skipping to change at line 530
CMSORIforPSKOtherInfo ::= SEQUENCE { CMSORIforPSKOtherInfo ::= SEQUENCE {
psk OCTET STRING, psk OCTET STRING,
keyMgmtAlgType ENUMERATED { keyMgmtAlgType ENUMERATED {
keyTrans (5), keyTrans (5),
keyAgree (10) }, keyAgree (10) },
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
pskLength INTEGER (1..MAX), pskLength INTEGER (1..MAX),
kdkLength INTEGER (1..MAX) } kdkLength INTEGER (1..MAX) }
END END ]]></sourcecode>
</section>
<CODE ENDS> <section anchor="sect-7" numbered="true" toc="default">
]]></artwork> <name>Security Considerations</name>
</figure> <t>
</section> The security considerations related to the CMS enveloped-data
content type in <xref target="RFC5652" format="default"/> and the security co
<section title="Security Considerations" anchor="sect-7"><t> nsiderations related to
The security considerations in related to the CMS enveloped-data the CMS authenticated-enveloped-data content type in <xref target="RFC5083" f
content type in <xref target="RFC5652"/> and the security considerations rela ormat="default"/>
ted to
the CMS authenticated-enveloped-data content type in <xref target="RFC5083"/>
continue to apply.</t> continue to apply.</t>
<t>
<t>
Implementations of the key derivation function must compute the Implementations of the key derivation function must compute the
entire result, which in this specification is a key-encryption key, entire result, which, in this specification, is a key-encryption key,
before outputting any portion of the result. The resulting key- before outputting any portion of the result. The resulting key-encryption ke
encryption key must be protected. Compromise of the key-encryption y must be protected. Compromise of the key-encryption
key may result in the disclosure of all content-encryption keys or key may result in the disclosure of all content-encryption keys or
content-authenticated-encryption keys that were protected with that content-authenticated-encryption keys that were protected with that
keying material, which in turn may result in the disclosure of the keying material; this, in turn, may result in the disclosure of the
content. Note that there are two key-encryption keys when a PSK with content. Note that there are two key-encryption keys when a PSK with
a key agreement algorithm is used, with similar consequence for the a key agreement algorithm is used, with similar consequences for the
compromise of either one of these keys.</t> compromise of either one of these keys.</t>
<t>
<t> Implementations must protect the PSK, key transport
Implementations must protect the pre-shared key (PSK), key transport private key, agreement private key, and key-derivation key.
private key, the agreement private key, and the key-derivation key.
Compromise of the PSK will make the encrypted content vulnerable to Compromise of the PSK will make the encrypted content vulnerable to
the future invention of a large-scale quantum computer. Compromise the future invention of a large-scale quantum computer. Compromise
of the PSK and either the key transport private key or the agreement of the PSK and either the key transport private key or the agreement
private key may result in the disclosure of all contents protected private key may result in the disclosure of all contents protected
with that combination of keying material. Compromise of the PSK and with that combination of keying material. Compromise of the PSK and
the key-derivation key may result in disclosure of all contents the key-derivation key may result in the disclosure of all contents
protected with that combination of keying material.</t> protected with that combination of keying material.</t>
<t>
<t>
A large-scale quantum computer will essentially negate the security A large-scale quantum computer will essentially negate the security
provided by the key transport algorithm or the key agreement provided by the key transport algorithm or the key agreement
algorithm, which means that the attacker with a large-scale quantum algorithm, which means that the attacker with a large-scale quantum
computer can discover the key-derivation key. In addition a large- computer can discover the key-derivation key. In addition, a large-scale qua
scale quantum computer effectively cuts the security provided by a ntum computer effectively cuts the security provided by a
symmetric key algorithm in half. Therefore, the PSK needs at least symmetric key algorithm in half. Therefore, the PSK needs at least
256 bits of entropy to provide 128 bits of security. To match that 256 bits of entropy to provide 128 bits of security. To match that
same level of security, the key derivation function needs to be same level of security, the key derivation function needs to be
quantum-resistant and produce a key-encryption key that is at least quantum resistant and produce a key-encryption key that is at least
256 bits in length. Similarly, the content-encryption key or 256 bits in length. Similarly, the content-encryption key or
content-authenticated-encryption key needs to be at least 256 bits in content-authenticated-encryption key needs to be at least 256 bits in
length.</t> length.</t>
<t>
<t>
When using a PSK with a key transport or a key agreement algorithm, a 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 key-encryption key is produced to encrypt the content-encryption key
or content-authenticated-encryption key. If the key-encryption or content-authenticated-encryption key. If the key-encryption
algorithm is different than the algorithm used to protect the algorithm is different than the algorithm used to protect the
content, then the effective security is determined by the weaker of content, then the effective security is determined by the weaker of
the two algorithms. If, for example, content is encrypted with the two algorithms. If, for example, content is encrypted with
256-bit AES, and the key is wrapped with 128-bit AES, then at most 256-bit AES and the key is wrapped with 128-bit AES, then, at most, 128 bits
128 bits of protection is provided. Implementers must ensure that of protection are provided. Implementers must ensure that
the key-encryption algorithm is as strong or stronger than the the key-encryption algorithm is as strong or stronger than the
content-encryption algorithm or content-authenticated-encryption content-encryption algorithm or content-authenticated-encryption
algorithm.</t> algorithm.</t>
<t>
<t>
The selection of the key-derivation function imposes an upper bound The selection of the key-derivation function imposes an upper bound
on the strength of the resulting key-encryption key. The strength of 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 selected key-derivation function should be at least as strong as
the key-encryption algorithm that is selected. NIST SP 800-56C the key-encryption algorithm that is selected. NIST SP 800-56C
Revision 1 <xref target="NIST2018"/> offers advice on the security strength o f Revision 1 <xref target="NIST2018" format="default"/> offers advice on the se curity strength of
several popular key-derivation functions.</t> several popular key-derivation functions.</t>
<t>
<t>
Implementers should not mix quantum-resistant key management Implementers should not mix quantum-resistant key management
algorithms with their non-quantum-resistant counterparts. For algorithms with their non-quantum-resistant counterparts. For
example, the same content should not be protected with example, the same content should not be protected with
KeyTransRecipientInfo and KeyTransPSKRecipientInfo. Likewise, the KeyTransRecipientInfo and KeyTransPSKRecipientInfo. Likewise, the
same content should not be protected with KeyAgreeRecipientInfo and same content should not be protected with KeyAgreeRecipientInfo and
KeyAgreePSKRecipientInfo. Doing so would make the content vulnerable KeyAgreePSKRecipientInfo. Doing so would make the content vulnerable
to the future invention of a large-scale quantum computer.</t> to the future invention of a large-scale quantum computer.</t>
<t>
<t>
Implementers should not send the same content in different messages, Implementers should not send the same content in different messages,
one using a quantum-resistant key management algorithm and the other one using a quantum-resistant key management algorithm and the other
using a non-quantum-resistant key management algorithm, even if the using a non-quantum-resistant key management algorithm, even if the
content-encryption key is generated independently. Doing so may content-encryption key is generated independently. Doing so may
allow an eavesdropper to correlate the messages, making the content allow an eavesdropper to correlate the messages, making the content
vulnerable to the future invention of a large-scale quantum computer.</t> vulnerable to the future invention of a large-scale quantum computer.</t>
<t>
<t> This specification does not require that PSK be known only by the
This specification does not require that PSK is known only by the
sender and recipients. The PSK may be known to a group. Since sender and recipients. The PSK may be known to a group. Since
confidentiality depends on the key transport or key agreement confidentiality depends on the key transport or key agreement
algorithm, knowledge of the PSK by other parties does not enable algorithm, knowledge of the PSK by other parties does not inherently enable
inherently eavesdropping. However, group members can record the eavesdropping. However, group members can record the
traffic of other members, and then decrypt it if they ever gain traffic of other members and then decrypt it if they ever gain
access to a large-scale quantum computer. Also, when many parties 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 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 attacker. Once an attacker has the PSK, they can decrypt stored
traffic if they ever gain access to a large-scale quantum computer in traffic if they ever gain access to a large-scale quantum computer in
the same manner as a legitimate group member.</t> the same manner as a legitimate group member.</t>
<t>
<t>
Sound cryptographic key hygiene is to use a key for one and only one 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 purpose. Use of the recipient's public key for both the traditional
CMS and the PSK-mixing variation specified in this document would be 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 a violation of this principle; however, there is no known way for an
attacker to take advantage of this situation. That said, an attacker to take advantage of this situation. That said, an
application should enforce separation whenever possible. For application should enforce separation whenever possible. For example, a pur
example, a purpose identifier for use in the X.509 extended key usage pose identifier for use in the X.509 extended key usage
certificate extension <xref target="RFC5280"/> could be identified in the fut certificate extension <xref target="RFC5280" format="default"/> could be identi
ure to fied in the future to
indicate that a public key should only be used in conjunction with a indicate that a public key should only be used in conjunction with or
PSK, or only without.</t> without a PSK.</t>
<t>
<t>
Implementations must randomly generate key-derivation keys as well as Implementations must randomly generate key-derivation keys as well as
the content-encryption keys or content-authenticated-encryption keys. content-encryption keys or content-authenticated-encryption keys.
Also, the generation of public/private key pairs for the key Also, the generation of public/private key pairs for the key
transport and key agreement algorithms rely on a random numbers. The transport and key agreement algorithms rely on random numbers. The
use of inadequate pseudo-random number generators (PRNGs) to generate use of inadequate pseudorandom number generators (PRNGs) to generate
cryptographic keys can result in little or no security. An attacker cryptographic keys can result in little or no security. An attacker
may find it much easier to reproduce the PRNG environment that may find it much easier to reproduce the PRNG environment that
produced the keys, searching the resulting small set of produced the keys, searching the resulting small set of
possibilities, rather than brute force searching the whole key space. possibilities, rather than brute-force searching the whole key space.
The generation of quality random numbers is difficult. <xref target="RFC4086 The generation of quality random numbers is difficult. <xref target="RFC4086
"/> " format="default"/>
offers important guidance in this area.</t> offers important guidance in this area.</t>
<t>
<t>
Implementers should be aware that cryptographic algorithms become Implementers should be aware that cryptographic algorithms become
weaker with time. As new cryptanalysis techniques are developed and weaker with time. As new cryptanalysis techniques are developed and
computing performance improves, the work factor to break a particular computing performance improves, the work factor to break a particular
cryptographic algorithm will be reduced. Therefore, cryptographic cryptographic algorithm will be reduced. Therefore, cryptographic
algorithm implementations should be modular, allowing new algorithms algorithm implementations should be modular, allowing new algorithms
to be readily inserted. That is, implementers should be prepared for to be readily inserted. That is, implementers should be prepared for
the set of supported algorithms to change over time.</t> the set of supported algorithms to change over time.</t>
<t>
<t>
The security properties provided by the mechanisms specified in this The security properties provided by the mechanisms specified in this
document can be validated using formal methods. A ProVerif proof in document can be validated using formal methods. A ProVerif proof in
<xref target="H2019"/> shows that an attacker with a large-scale quantum comp uter <xref target="H2019" format="default"/> shows that an attacker with a large-s cale quantum computer
that is capable of breaking the Diffie-Hellman key agreement that is capable of breaking the Diffie-Hellman key agreement
algorithm cannot disrupt the delivery of the content-encryption key algorithm cannot disrupt the delivery of the content-encryption key
to the recipient and the attacker cannot learn the content-encryption to the recipient and that the attacker cannot learn the content-encryption
key from the protocol exchange.</t> key from the protocol exchange.</t>
</section>
<section anchor="sect-8" numbered="true" toc="default">
<name>Privacy Considerations</name>
</section> <t>
<section title="Privacy Considerations" anchor="sect-8"><t>
An observer can see which parties are using each PSK simply by An observer can see which parties are using each PSK simply by
watching the PSK key identifiers. However, the addition of these key watching the PSK key identifiers. However, the addition of these key identif
identifiers is not really making privacy worse. When key transport iers does not really weaken
the privacy situation. When key transport
is used, the RecipientIdentifier is always present, and it clearly is used, the RecipientIdentifier is always present, and it clearly
identifies each recipient to an observer. When key agreement is identifies each recipient to an observer. When key agreement is
used, either the IssuerAndSerialNumber or the RecipientKeyIdentifier used, either the IssuerAndSerialNumber or the RecipientKeyIdentifier
is always present, and these clearly identify each recipient.</t> is always present, and these clearly identify each recipient.</t>
</section>
<section anchor="sect-9" numbered="true" toc="default">
<name>IANA Considerations</name>
</section> <t>
One object identifier for the ASN.1 module in <xref target="sect-6" format="d
<section title="IANA Considerations" anchor="sect-9"><t> efault"/> was assigned
One object identifier for the ASN.1 module in <xref target="sect-6"/> was ass in the "SMI Security for S/MIME Module Identifier
igned (1.2.840.113549.1.9.16.0)" registry <xref target="IANA" format="default"/>:</
in the SMI Security for S/MIME Module Identifiers t>
(1.2.840.113549.1.9.16.0) <xref target="IANA-MOD"/> registry:</t> <sourcecode name="" type="asn.1"><![CDATA[
<figure><artwork><![CDATA[
id-mod-cms-ori-psk-2019 OBJECT IDENTIFIER ::= { id-mod-cms-ori-psk-2019 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) mod(0) TBD0 } pkcs-9(9) smime(16) mod(0) 69 } ]]></sourcecode>
]]></artwork> <t>
</figure> One new entry has been added in the "SMI Security for S/MIME Mail
<t> Security (1.2.840.113549.1.9.16)" registry <xref target="IANA" format="def
One new registry was created for Other Recipient Info Identifiers ault"/>:</t>
within the SMI Security for S/MIME Mail Security <sourcecode name="" type="asn.1"><![CDATA[
(1.2.840.113549.1.9.16) <xref target="IANA-SMIME"/> registry:</t>
<figure><artwork><![CDATA[
id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 } ]]></sourcecode>
]]></artwork> <t>A new registry titled "SMI Security for S/MIME Other
</figure> Recipient Info Identifiers (1.2.840.113549.1.9.16.13)" has been created.
<t>
</t>
<t>
Updates to the new registry are to be made according to the Updates to the new registry are to be made according to the
Specification Required policy as defined in <xref target="RFC8126"/>. The ex Specification Required policy as defined in <xref target="RFC8126" format="de
pert is fault"/>. The expert is expected to ensure that any new values identify additio
expected to ensure that any new values identify additions nal
RecipientInfo structures for use with the CMS. Object identifiers RecipientInfo structures for use with the CMS. Object identifiers
for other purposes should not be assigned in this arc.</t> for other purposes should not be assigned in this arc.</t>
<t>
<t> Two assignments were made in the new "SMI Security for S/MIME Other Recipient
Two assignments were made in the new SMI Security for Other Recipient Info Identifiers (1.2.840.113549.1.9.16.13)" registry <xref target="IANA" for
Info Identifiers (1.2.840.113549.1.9.16.TBD1) <xref target="IANA-ORI"/> regis mat="default"/>
try
with references to this document:</t> with references to this document:</t>
<sourcecode name="" type="asn.1"><![CDATA[
<figure><artwork><![CDATA[
id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori-keyTransPSK OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-ori(TBD1) 1 } pkcs-9(9) smime(16) id-ori(13) 1 }
id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori-keyAgreePSK OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-ori(TBD1) 2 } pkcs-9(9) smime(16) id-ori(13) 2 } ]]></sourcecode>
]]></artwork> </section>
</figure> </middle>
</section> <back>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC5083;
&RFC5652;
&RFC5912;
&RFC6268;
&RFC8126;
&RFC8174;
<reference anchor="X680"><front>
<title>Information technology -- Abstract Syntax Notation One (ASN.1): Sp
ecification of basic notation</title>
<author>
<organization>ITU-T</organization>
</author>
<date year="2015"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation X.680"/>
</reference>
<reference anchor="X690"><front>
<title>Information technology -- ASN.1 encoding rules: Specification of B
asic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Enco
ding Rules (DER)</title>
<author>
<organization>ITU-T</organization>
</author>
<date year="2015"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation X.690"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="AES"><front>
<title>FIPS Pub 197: Advanced Encryption Standard (AES)</title>
<author>
<organization>National Institute of Standards and Technology</organizatio
n>
</author>
<date month="26" year="November 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>
<reference anchor="FGHT2016" target="https://eprint.iacr.org/2016/961.pdf
"><front>
<title>A kilobit hidden SNFS discrete logarithm computation</title>
<author fullname="J. Fried" initials="J." surname="Fried">
</author>
<author fullname="P. Gaudry" initials="P." surname="Gaudry">
</author>
<author fullname="N. Heninger" initials="N." surname="Heninger">
</author>
<author fullname="E. Thome" initials="E." surname="Thome">
</author>
<date year="2016"/>
</front>
<seriesInfo name="Cryptology" value="ePrint Archive Report 2016/961"/> <displayreference target="I-D.hoffman-c2pq" to="C2PQ"/>
</reference>
<reference anchor="H2019" target="https://mailarchive.ietf.org/arch/msg/s
pasm/_6d_4jp3sOprAnbU2fp_yp_-6-k"><front>
<title>Re: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk"</t
itle>
<author fullname="J. Hammell" initials="J." surname="Hammell">
</author>
<date month="May" year="2019"/> <references>
</front> <name>References</name>
</reference> <references>
<reference anchor="IANA-MOD" target="https://www.iana.org/assignments/smi <name>Normative References</name>
-numbers/smi-numbers.xhtml#security-smime-0"><front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<title>IANA-MOD</title> FC.2119.xml"/>
<author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</author> FC.5083.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5652.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5912.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6268.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<date/> <reference anchor="X680">
</front> <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>
</reference>
</reference> <reference anchor="X690">
<reference anchor="IANA-SMIME" target="https://www.iana.org/assignments/s <front>
mi-numbers/smi-numbers.xhtml#security-smime"><front> <title>Information technology -- ASN.1 encoding rules: Specification
<title>IANA-SMIME</title> of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
<author> Encoding Rules (DER)</title>
</author> <seriesInfo name="ITU-T" value="Recommendation X.690"/>
<author>
<organization>ITU-T</organization>
</author>
<date month="August" year="2015"/>
</front>
</reference>
<date/> </references>
</front> <references>
</reference> <name>Informative References</name>
<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>
<date/> <reference anchor="AES">
</front> <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</orga
nization>
</author>
<date month="November" year="2001"/>
</front>
</reference>
</reference> <!-- <reference anchor="I-D.hoffman-c2pq">; I-D Exists -->
<reference anchor="NAS2019"><front> <xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.
<title>Quantum Computing: Progress and Prospects</title> hoffman-c2pq.xml"/>
<author>
<organization>National Academies of Sciences, Engineering, and Medicine</
organization>
</author>
<date year="2019"/> <reference anchor="FGHT2016" target="https://eprint.iacr.org/2016/961.pd
</front> f">
<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 fullname="P. Gaudry" initials="P." surname="Gaudry"/>
<author fullname="N. Heninger" initials="N." surname="Heninger"/>
<author fullname="E. Thome" initials="E." surname="Thome"/>
<date year="2016" month="October"/>
</front>
</reference>
<seriesInfo name="The" value="National Academies Press DOI 10.17226/25196 <reference anchor="H2019" target="https://mailarchive.ietf.org/arch/msg/
"/> spasm/_6d_4jp3sOprAnbU2fp_yp_-6-k">
</reference> <front>
<reference anchor="NIST2018" target="https://nvlpubs.nist.gov/nistpubs/Sp <title>Subject: [lamps] WG Last Call for
ecialPublications/NIST.SP.800-56Cr1.pdf"><front> draft-ietf-lamps-cms-mix-with-psk"</title>
<title>Recommendation for Key-Derivation Methods in Key-Establishment Sch <author fullname="J. Hammell" initials="J." surname="Hammell"/>
emes</title> <date month="May" year="2019"/>
<author fullname="E. Barker" initials="E." surname="Barker"> </front>
</author> <refcontent> message to the IETF mailing list</refcontent>
</reference>
<author fullname="L. Chen" initials="L." surname="Chen"> <reference anchor="IANA" target="https://www.iana.org/assignments/smi-nu
</author> mbers">
<front>
<title>Structure of Management Information (SMI) Numbers (MIB Module
Registrations)</title>
<author><organization>IANA</organization></author>
<date/>
</front>
</reference>
<author fullname="R. Davis" initials="R." surname="Davis"> <reference anchor="NAS2019">
</author> <front>
<title>Quantum Computing: Progress and Prospects</title>
<seriesInfo name="DOI" value="10.17226/25196"/>
<author>
<organization>National Academies of Sciences, Engineering, and Med
icine</organization>
</author>
<date year="2019"/>
</front>
</reference>
<date month="April" year="2018"/> <reference anchor="NIST2018" target="https://nvlpubs.nist.gov/nistpubs/S
</front> pecialPublications/NIST.SP.800-56Cr1.pdf">
<front>
<title>Recommendation for Key-Derivation Methods in Key-Establishmen
t Schemes</title>
<seriesInfo name="NIST Special Publication" value="800-56C Revision
1"/>
<author fullname="E. Barker" initials="E." surname="Barker"/>
<author fullname="L. Chen" initials="L." surname="Chen"/>
<author fullname="R. Davis" initials="R." surname="Davis"/>
<date month="April" year="2018"/>
</front>
</reference>
<seriesInfo name="NIST" value="Special Publication 800-56C Rev. 1"/> <reference anchor="S1994">
</reference> <front>
<reference anchor="S1994"><front> <title>Algorithms for Quantum Computation: Discrete Logarithms and F
<title>Algorithms for Quantum Computation: Discrete Logarithms and Factor actoring</title>
ing</title> <author fullname="P. Shor" initials="P." surname="Shor"/>
<author fullname="P. Shor" initials="P." surname="Shor"> <date year="1994" month="November"/>
</author> </front>
<refcontent>Proceedings of the 35th Annual Symposium on Foundations
of Computer Science, pp. 124-134"</refcontent>
</reference>
<date year="1994"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.2631.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4086.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5280.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5753.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5869.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8017.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8619.xml"/>
</references>
</references>
<seriesInfo name="Proceedings" value="of the 35th Annual Symposium on Fou <section anchor="sect-a" numbered="true" toc="default">
ndations of Computer Science pp. 124-134"/> <name>Key Transport with PSK Example</name>
</reference> <t>
&RFC2631;
&RFC4086;
&RFC5280;
&RFC5753;
&RFC5869;
&RFC8017;
&RFC8619;
</references>
<section title="Key Transport with PSK Example" anchor="sect-a"><t>
This example shows the establishment of an AES-256 content-encryption This example shows the establishment of an AES-256 content-encryption
key using:</t> key using:</t>
<ul spacing="normal">
<t><list style="symbols" hangIndent="3"> <li>a pre-shared key of 256 bits;</li>
<t>a pre-shared key of 256 bits;</t> <li>key transport using RSA PKCS#1 v1.5 with a 3072-bit key;</li>
<t>key transport using RSA PKCS#1 v1.5 with a 3072-bit key;</t> <li>key derivation using HKDF with SHA-384; and</li>
<t>key derivation using HKDF with SHA-384; and</t> <li>key wrap using AES-256-KEYWRAP.</li>
<t>key wrap using AES-256-KEYWRAP.</t> </ul>
</list> <t>
</t>
<t>
In real-world use, the originator would encrypt the key-derivation 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 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> key. This is omitted in an attempt to simplify the example.</t>
<section anchor="sect-a.1" numbered="true" toc="default">
<section title="Originator Processing Example" anchor="sect-a.1"> <name>Originator Processing Example</name>
<t> The pre-shared key known to Alice and Bob, in hexadecimal, is:</t>
<t> The pre-shared key known to Alice and Bob, in hexadecimal:</t> <sourcecode type="test-vectors"><![CDATA[
c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb05213365cf95b15 ]]></sourcec
<figure><artwork> ode>
c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb05213365cf95b15 <t> The identifier assigned to the pre-shared key is:</t>
</artwork></figure> <sourcecode type="test-vectors"><![CDATA[
ptf-kmc:13614122112 ]]></sourcecode>
<t> The identifier assigned to the pre-shared key is:</t> <t>Alice obtains Bob's public key:</t>
<figure><artwork> <sourcecode type="test-vectors"><![CDATA[
ptf-kmc:13614122112
</artwork></figure>
<t>Alice obtains Bob's public key:</t>
<figure><artwork><![CDATA[
-----BEGIN PUBLIC KEY----- -----BEGIN PUBLIC KEY-----
MIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEA3ocW14cxncPJ47fnEjBZ MIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEA3ocW14cxncPJ47fnEjBZ
AyfC2lqapL3ET4jvV6C7gGeVrRQxWPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JH AyfC2lqapL3ET4jvV6C7gGeVrRQxWPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JH
Keeza+itfuhsz3yifgeEpeK8T+SusHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqq Keeza+itfuhsz3yifgeEpeK8T+SusHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqq
vS3jg/VO+OPnZbofoHOOevt8Q/roahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx vS3jg/VO+OPnZbofoHOOevt8Q/roahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx
2AHHZJevo3nmRnlgJXo6mE00E/6qkhjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0v 2AHHZJevo3nmRnlgJXo6mE00E/6qkhjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0v
SH7qUl8/vN13y4UOFkn8hM4kmZ6bJqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39a SH7qUl8/vN13y4UOFkn8hM4kmZ6bJqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39a
uLNnH3EXdXaV1tk75H3qC7zJaeGWMJyQfOE3YfEGRKn8fxubji716D8UecAxAzFy uLNnH3EXdXaV1tk75H3qC7zJaeGWMJyQfOE3YfEGRKn8fxubji716D8UecAxAzFy
FL6m1JiOyV5acAiOpxN14qRYZdHnXOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fS FL6m1JiOyV5acAiOpxN14qRYZdHnXOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fS
whSZG7VNf+vgNWTLNYSYLI04KiMdulnvU6ds+QPz+KKtAgMBAAE= whSZG7VNf+vgNWTLNYSYLI04KiMdulnvU6ds+QPz+KKtAgMBAAE=
-----END PUBLIC KEY----- -----END PUBLIC KEY----- ]]></sourcecode>
]]></artwork> <t> Bob's RSA public key has the following key identifier: </t>
</figure> <sourcecode type="test-vectors"><![CDATA[
9eeb67c9b95a74d44d2f16396680e801b5cba49c ]]></sourcecode>
<t> Bob's RSA public key has the following key identifier: </t> <t> Alice randomly generates a content-encryption key: </t>
<figure><artwork> <sourcecode type="test-vectors"><![CDATA[
9eeb67c9b95a74d44d2f16396680e801b5cba49c c8adc30f4a3e20ac420caa76a68f5787c02ab42afea20d19672fd963a5338e83 ]]></sourcec
</artwork></figure> ode>
<t> Alice randomly generates a key-derivation key: </t>
<t> Alice randomly generates a content-encryption key: </t> <sourcecode type="test-vectors"><![CDATA[
<figure><artwork> df85af9e3cebffde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde81eb ]]></sourcec
c8adc30f4a3e20ac420caa76a68f5787c02ab42afea20d19672fd963a5338e83 ode>
</artwork></figure> <t> Alice encrypts the key-derivation key in Bob's public key: </t>
<sourcecode type="test-vectors"><![CDATA[
<t> Alice randomly generates a key-derivation key: </t> 52693f12140c91dea2b44c0b7936f6be46de8a7bfab072bcb6ecfd56b06a9f65
<figure><artwork> 1bd4669d336aef7b449e5cd9b151893b7c7a3b8e364394840b0a5434cbf10e1b
df85af9e3cebffde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde81eb 5670aefd074faf380665d204fb95153543346f36c2125dba6f4d23d2bc61434b
</artwork></figure> 5e36ff72b3eafe57c6cf7f74924c309f174b0b8753554b58ed33a8848d707a98
c0c2b1ddcfd09e31fe213ca0a48dd157bd7d842e85cc76f77710d58efeaa0525
<t> Alice encrypts the key-derivation key in Bob's public key: </t> c651bcd1410fb47534ecabaf5ab7daabed809d4b97220caf6d4929c5fb684f7b
b8692e6e70332ff9b3f7c11d6cac51d4a35593173d48f80ca843b89789d625e7
<figure><artwork><![CDATA[ 997ad7d674d25a2a7d165a5f39b3cb6358e937bdb02ac8a524ac93113cedd9ad
4e6200431ed95e0e28f7288dba56d4b90e75959e068884664c43368f3d978f3d c68263025c0bb0997d716e58d4d7b69739bf591f3e71c7678dc0df96f3df9e8a
8179e5837e3c27bf8dc1f6e2827b9ede969be77417516de07d90e37c560add01 a5738f4f9ce21489f300e040891b20b2ab6d9051b3c2e68efa2fa9799a706878
48deb0c9178088ccb72c068d8a9076b6a5e7ecc9093e30fdeaecc9e138d80626 d5f462018c021d6669ed649f9acdf78476810198bfb8bd41ffedc585eafa957e
74fcf685f3082b910839551cd8741beedeee6e87c08ff84f03ba87118730cdf7 ea1d3625e4bed376e7ae49718aee2f575c401a26a29941d8da5b7ee9aca36471 ]]></sourcec
667002316f1a29a6cc596c7ddf95a51e398927d1916bf27929945de080fc7c80 ode>
6af6281aed6492acffa4ef1b4f53e67fca9a417db2350a2277d586ee3cabefd3 <t> Alice produces a 256-bit key-encryption key with HKDF using
b4a44f04d3c6803d54fe9a7159210dabedda9a94f310d303331da51c0218d92a SHA-384; the secret value is the key-derivation key; and the 'info' is th
2efb003792259195a9fd4cc403af613fdf1a6265ea70bf702fd1c6f734264c9a e DER-encoded CMSORIforPSKOtherInfo structure with the following values: </t>
59196e8e8fd657fa028e272ef741eb7711fd5b3f4ea7da9c33df66bf487da710 <sourcecode type="test-vectors"><![CDATA[
1c9bbfddaf1c073900a3ea99da513d8aa32605db07dc1c47504cab30c9304a85 0 56: SEQUENCE {
d87377f603ec3df4056ddcf3d756fb7ed98254421a4ae151f17ad4e28c5ea077 2 32: OCTET STRING
63358dfb1ef5f73435f337b21a38c1a3fa697a530dd97e462f6b5fb2052a2d53 : C2 44 CD D1 1A 0D 1F 39 D9 B6 12 82 77 02 44 FB
]]></artwork> : 0F 6B EF B9 1A B7 F9 6C B0 52 13 36 5C F9 5B 15
</figure> 36 1: ENUMERATED 5
39 11: SEQUENCE {
<t> Alice produces a 256-bit key-encryption key with HKDF using SHA-384; 41 9: OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45)
the secret value is the key-derivation key; the 'info' is the DER- : }
encoded CMSORIforPSKOtherInfo structure with the following values: </t> 52 1: INTEGER 32
55 1: INTEGER 32
<figure><artwork><![CDATA[ : } ]]></sourcecode>
0 56: SEQUENCE { <t> The DER encoding of CMSORIforPSKOtherInfo produces 58 octets:</t>
2 32: OCTET STRING <sourcecode type="test-vectors">
: C2 44 CD D1 1A 0D 1F 39 D9 B6 12 82 77 02 44 FB <![CDATA[ 30380420c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb0521336
: 0F 6B EF B9 1A B7 F9 6C B0 52 13 36 5C F9 5B 15 5cf95b150a0105300b060960864801650304012d020120020120 ]]></sourcecode>
36 1: ENUMERATED 5 <t>The HKDF output is 256 bits:</t>
39 11: SEQUENCE { <sourcecode type="test-vectors">
41 9: OBJECT IDENTIFIER aes256-wrap <![CDATA[ f319e9cebb35f1c6a7a9709b8760b9d0d3e30e16c5b2b69347e9f00ca540a232 ]]><
: { 2 16 840 1 101 3 4 1 45 } /sourcecode>
: } <t> Alice uses AES-KEY-WRAP to encrypt the 256-bit content-encryption ke
52 1: INTEGER 32 y with the key-encryption key:</t>
55 1: INTEGER 32 <sourcecode type="test-vectors">
: } <![CDATA[ ea0947250fa66cd525595e52a69aaade88efcf1b0f108abe291060391b1cdf59
07f36b4067e45342 ]]></sourcecode>
]]></artwork> <t>Alice encrypts the content using AES-256-GCM with the content-encrypt
</figure> ion key. The 12-octet nonce used is:</t>
<sourcecode type="test-vectors">
<t> The DER encoding of CMSORIforPSKOtherInfo produces 58 octets:</t> <![CDATA[ cafebabefacedbaddecaf888 ]]></sourcecode>
<figure><artwork> <t>The content plaintext is:</t>
30380420c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb0521336 <sourcecode type="test-vectors">
5cf95b150a0105300b060960864801650304012d020120020120 <![CDATA[ 48656c6c6f2c20776f726c6421 ]]></sourcecode>
</artwork></figure> <t>The resulting ciphertext is:</t>
<sourcecode type="test-vectors">
<t>The HKDF output is 256 bits:</t> <![CDATA[ 9af2d16f21547fcefed9b3ef2d ]]></sourcecode>
<figure><artwork> <t>The resulting 12-octet authentication tag is:</t>
a14d87451dfd11d83cd54ffe2bd38c49a2adfed3ac49f1d3e62bbdc64ae43b32 <sourcecode type="test-vectors">
</artwork></figure> <![CDATA[ a0e5925cc184e0172463c44c ]]></sourcecode>
</section>
<t> Alice uses AES-KEY-WRAP to encrypt the 256-bit content-encryption key wi <section anchor="sect-a.2" numbered="true" toc="default">
th the key-encryption key:</t> <name>ContentInfo and AuthEnvelopedData</name>
<figure><artwork> <t>
ae4ea1d99e78fcdcea12d9f10d991ac71502939ee0c30ebdcc97dd1fc5ba3566 Alice encodes the AuthEnvelopedData and the ContentInfo and
c83d0dd5d1b4faa5
</artwork></figure>
<t>Alice encrypts the content using AES-256-GCM with the content-encryption k
ey. The 12-octet nonce used is:</t>
<figure><artwork>
cafebabefacedbaddecaf888
</artwork></figure>
<t>The content plaintext is:</t>
<figure><artwork>
48656c6c6f2c20776f726c6421
</artwork></figure>
<t>The resulting ciphertext is:</t>
<figure><artwork>
9af2d16f21547fcefed9b3ef2d
</artwork></figure>
<t>The resulting 12-octet authentication tag is:</t>
<figure><artwork>
a0e5925cc184e0172463c44c
</artwork></figure>
</section>
<section title="ContentInfo and AuthEnvelopedData" anchor="sect-a.2"><t>
Alice encodes the AuthEnvelopedData and the ContentInfo, and
sends the result to Bob. The resulting structure is:</t> sends the result to Bob. The resulting structure is:</t>
<sourcecode type="test-vectors"><![CDATA[
<figure><artwork><![CDATA[
0 650: SEQUENCE { 0 650: SEQUENCE {
4 11: OBJECT IDENTIFIER authEnvelopedData 4 11: OBJECT IDENTIFIER
: { 1 2 840 113549 1 9 16 1 23 } : authEnvelopedData (1 2 840 113549 1 9 16 1 23)
17 633: [0] { 17 633: [0] {
21 629: SEQUENCE { 21 629: SEQUENCE {
25 1: INTEGER 0 25 1: INTEGER 0
28 551: SET { 28 551: SET {
32 547: [4] { 32 547: [4] {
36 11: OBJECT IDENTIFIER ** Placeholder ** 36 11: OBJECT IDENTIFIER
: { 1 2 840 113549 1 9 16 TBD 1 } : keyTransPSK (1 2 840 113549 1 9 16 13 1)
49 530: SEQUENCE { 49 530: SEQUENCE {
53 1: INTEGER 0 53 1: INTEGER 0
56 19: OCTET STRING 'ptf-kmc:13614122112' 56 19: OCTET STRING 'ptf-kmc:13614122112'
77 13: SEQUENCE { 77 13: SEQUENCE {
79 11: OBJECT IDENTIFIER ** Placeholder ** 79 11: OBJECT IDENTIFIER
: { 1 2 840 113549 1 9 16 3 TBD } : hkdf-with-sha384 (1 2 840 113549 1 9 16 3 29)
: } : }
92 11: SEQUENCE { 92 11: SEQUENCE {
94 9: OBJECT IDENTIFIER aes256-wrap 94 9: OBJECT IDENTIFIER
: { 2 16 840 1 101 3 4 1 45 } : aes256-wrap (2 16 840 1 101 3 4 1 45)
: } : }
105 432: SEQUENCE { 105 432: SEQUENCE {
109 428: SEQUENCE { 109 428: SEQUENCE {
113 1: INTEGER 2 113 1: INTEGER 2
116 20: [0] 116 20: [0]
: 9E EB 67 C9 B9 5A 74 D4 4D 2F 16 39 66 80 E8 01 : 9E EB 67 C9 B9 5A 74 D4 4D 2F 16 39 66 80 E8 01
: B5 CB A4 9C : B5 CB A4 9C
138 13: SEQUENCE { 138 13: SEQUENCE {
140 9: OBJECT IDENTIFIER rsaEncryption 140 9: OBJECT IDENTIFIER
: { 1 2 840 113549 1 1 1 } : rsaEncryption (1 2 840 113549 1 1 1)
151 0: NULL 151 0: NULL
: } : }
153 384: OCTET STRING 153 384: OCTET STRING
: 18 09 D6 23 17 DF 2D 09 55 57 3B FE 75 95 EB 6A : 52 69 3F 12 14 0C 91 DE A2 B4 4C 0B 79 36 F6 BE
: 3D 57 84 6C 69 C1 49 0B F1 11 1A BB 40 0C D8 B5 : 46 DE 8A 7B FA B0 72 BC B6 EC FD 56 B0 6A 9F 65
: 26 5F D3 62 4B E2 D8 E4 CA EC 6A 12 36 CA 38 E3 : 1B D4 66 9D 33 6A EF 7B 44 9E 5C D9 B1 51 89 3B
: A0 7D AA E0 5F A1 E3 BC 59 F3 AD A8 8D 95 A1 6B : 7C 7A 3B 8E 36 43 94 84 0B 0A 54 34 CB F1 0E 1B
: 06 85 20 93 C7 C5 C0 05 62 ED DF 02 1D FE 68 7C : 56 70 AE FD 07 4F AF 38 06 65 D2 04 FB 95 15 35
: 18 A1 3A AB AA 59 92 30 6A 1B 92 73 D5 01 C6 5B : 43 34 6F 36 C2 12 5D BA 6F 4D 23 D2 BC 61 43 4B
: FD 1E BB A9 B9 D2 7F 48 49 7F 3C 4F 3C 13 E3 2B : 5E 36 FF 72 B3 EA FE 57 C6 CF 7F 74 92 4C 30 9F
: 2A 19 F1 7A CD BC 56 28 EF 7F CA 4F 69 6B 7E 92 : 17 4B 0B 87 53 55 4B 58 ED 33 A8 84 8D 70 7A 98
: 66 22 0D 13 B7 23 AD 41 9E 5E 98 2A 80 B7 6C 77 : C0 C2 B1 DD CF D0 9E 31 FE 21 3C A0 A4 8D D1 57
: FF 9B 76 B1 04 BA 30 6D 4B 4D F9 25 57 E0 7F 0E : BD 7D 84 2E 85 CC 76 F7 77 10 D5 8E FE AA 05 25
: 95 9A 43 6D 14 D5 72 3F AA 8F 66 35 40 D0 E3 71 : C6 51 BC D1 41 0F B4 75 34 EC AB AF 5A B7 DA AB
: 4B 7F 20 9D ED 67 EA 33 79 CD AB 84 16 72 07 D2 : ED 80 9D 4B 97 22 0C AF 6D 49 29 C5 FB 68 4F 7B
: AC 8D 3A DA 12 43 B7 2F 3A CF 91 3E F1 D9 58 20 : B8 69 2E 6E 70 33 2F F9 B3 F7 C1 1D 6C AC 51 D4
: 6D F2 9C 09 E1 EC D2 0B 82 BE 5D 69 77 6F FE F7 : A3 55 93 17 3D 48 F8 0C A8 43 B8 97 89 D6 25 E7
: EB F6 31 C0 D9 B7 15 BF D0 24 F3 05 1F FF 48 76 : 99 7A D7 D6 74 D2 5A 2A 7D 16 5A 5F 39 B3 CB 63
: 1D 73 17 19 2C 38 C6 D5 86 BD 67 82 2D B2 61 AA : 58 E9 37 BD B0 2A C8 A5 24 AC 93 11 3C ED D9 AD
: 08 C7 E4 37 34 D1 2D E0 51 32 15 4A AC 6B 2B 28 : C6 82 63 02 5C 0B B0 99 7D 71 6E 58 D4 D7 B6 97
: 5B CD FA 7C 65 89 2F A2 63 DB AB 64 88 43 CC 66 : 39 BF 59 1F 3E 71 C7 67 8D C0 DF 96 F3 DF 9E 8A
: 27 84 29 AC 15 5F 3B 9E 5B DF 99 AE 4F 1B B2 BC : A5 73 8F 4F 9C E2 14 89 F3 00 E0 40 89 1B 20 B2
: 19 6C 17 A1 99 A5 CF F7 80 32 11 88 F1 9D B3 6F : AB 6D 90 51 B3 C2 E6 8E FA 2F A9 79 9A 70 68 78
: 4B 16 5F 3F 03 F7 D2 04 3D DE 5F 30 CD 8B BB 3A : D5 F4 62 01 8C 02 1D 66 69 ED 64 9F 9A CD F7 84
: 38 DA 9D EC 16 6C 36 4F 8B 7E 99 AA 99 FB 42 D6 : 76 81 01 98 BF B8 BD 41 FF ED C5 85 EA FA 95 7E
: 1A FF 3C 85 D7 A2 30 74 2C D3 AA F7 18 2A 25 3C : EA 1D 36 25 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 5B 5D : 5C 40 1A 26 A2 99 41 D8 DA 5B 7E E9 AC A3 64 71
: }
: } : }
: }
541 40: OCTET STRING 541 40: OCTET STRING
: AE 4E A1 D9 9E 78 FC DC EA 12 D9 F1 0D 99 1A C7 : EA 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 { 583 55: SEQUENCE {
585 9: OBJECT IDENTIFIER data { 1 2 840 113549 1 7 1 } 585 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
596 27: SEQUENCE { 596 27: SEQUENCE {
598 9: OBJECT IDENTIFIER aes256-GCM 598 9: OBJECT IDENTIFIER
: { 2 16 840 1 101 3 4 1 46 } : aes256-GCM (2 16 840 1 101 3 4 1 46)
609 14: SEQUENCE { 609 14: SEQUENCE {
611 12: OCTET STRING CA FE BA BE FA CE DB AD DE CA F8 88 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
: } : }
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 640 12: OCTET STRING A0 E5 92 5C C1 84 E0 17 24 63 C4 4C
: } : }
: } : }
: } : } ]]></sourcecode>
]]></artwork> </section>
</figure> <section anchor="sect-a.3" numbered="true" toc="default">
</section> <name>Recipient Processing Example</name>
<t>Bob's private key is:</t>
<section title="Recipient Processing Example" anchor="sect-a.3"> <sourcecode type="test-vectors"><![CDATA[
<t>Bob's private key:</t>
<figure><artwork><![CDATA[
-----BEGIN RSA PRIVATE KEY----- -----BEGIN RSA PRIVATE KEY-----
MIIG5AIBAAKCAYEA3ocW14cxncPJ47fnEjBZAyfC2lqapL3ET4jvV6C7gGeVrRQx MIIG5AIBAAKCAYEA3ocW14cxncPJ47fnEjBZAyfC2lqapL3ET4jvV6C7gGeVrRQx
WPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JHKeeza+itfuhsz3yifgeEpeK8T+Su WPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JHKeeza+itfuhsz3yifgeEpeK8T+Su
sHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqqvS3jg/VO+OPnZbofoHOOevt8Q/ro sHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqqvS3jg/VO+OPnZbofoHOOevt8Q/ro
ahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx2AHHZJevo3nmRnlgJXo6mE00E/6q ahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx2AHHZJevo3nmRnlgJXo6mE00E/6q
khjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0vSH7qUl8/vN13y4UOFkn8hM4kmZ6b khjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0vSH7qUl8/vN13y4UOFkn8hM4kmZ6b
JqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39auLNnH3EXdXaV1tk75H3qC7zJaeGW JqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39auLNnH3EXdXaV1tk75H3qC7zJaeGW
MJyQfOE3YfEGRKn8fxubji716D8UecAxAzFyFL6m1JiOyV5acAiOpxN14qRYZdHn MJyQfOE3YfEGRKn8fxubji716D8UecAxAzFyFL6m1JiOyV5acAiOpxN14qRYZdHn
XOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fSwhSZG7VNf+vgNWTLNYSYLI04KiMd XOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fSwhSZG7VNf+vgNWTLNYSYLI04KiMd
ulnvU6ds+QPz+KKtAgMBAAECggGATFfkSkUjjJCjLvDk4aScpSx6+Rakf2hrdS3x ulnvU6ds+QPz+KKtAgMBAAECggGATFfkSkUjjJCjLvDk4aScpSx6+Rakf2hrdS3x
skipping to change at line 1322 skipping to change at line 1068
B8oph/jD8O2YCk4YCTDOXPEi8Rjusxzro+whvRR+kG0gsGGcKSVNCPj1fNISEte4 B8oph/jD8O2YCk4YCTDOXPEi8Rjusxzro+whvRR+kG0gsGGcKSVNCPj1fNISEte4
gJId7O1mUAAzeDjn/VaS/PXQovEMolssPPKn9NocbKbpAoHBAJnFHJunl22W/lrr gJId7O1mUAAzeDjn/VaS/PXQovEMolssPPKn9NocbKbpAoHBAJnFHJunl22W/lrr
ppmPnIzjI30YVcYOA5vlqLKyGaAsnfYqP1WUNgfVhq2jRsrHx9cnHQI9Hu442PvI ppmPnIzjI30YVcYOA5vlqLKyGaAsnfYqP1WUNgfVhq2jRsrHx9cnHQI9Hu442PvI
x+c5H30YFJ4ipE3eRRRmAUi4ghY5WgD+1hw8fqyUW7E7l5LbSbGEUVXtrkU5G64T x+c5H30YFJ4ipE3eRRRmAUi4ghY5WgD+1hw8fqyUW7E7l5LbSbGEUVXtrkU5G64T
UR91LEyMF8OPATdiV/KD4PWYkgaqRm3tVEuCVACDTQkqNsOOi3YPQcm270w6gxfQ UR91LEyMF8OPATdiV/KD4PWYkgaqRm3tVEuCVACDTQkqNsOOi3YPQcm270w6gxfQ
SOEy/kdhCFexJFA8uZvmh6Cp2crczxyBilR/yCxqKOONqlFdOQKBwFbJk5eHPjJz SOEy/kdhCFexJFA8uZvmh6Cp2crczxyBilR/yCxqKOONqlFdOQKBwFbJk5eHPjJz
AYueKMQESPGYCrwIqxgZGCxaqeVArHvKsEDx5whI6JWoFYVkFA8F0MyhukoEb/2x AYueKMQESPGYCrwIqxgZGCxaqeVArHvKsEDx5whI6JWoFYVkFA8F0MyhukoEb/2x
2qB5T88Dg3EbqjTiLg3qxrWJ2OxtUo8pBP2I2wbl2NOwzcbrlYhzEZ8bJyxZu5i1 2qB5T88Dg3EbqjTiLg3qxrWJ2OxtUo8pBP2I2wbl2NOwzcbrlYhzEZ8bJyxZu5i1
sYILC8PJ4Qzw6jS4Qpm4y1WHz8e/ElW6VyfmljZYA7f9WMntdfeQVqCVzNTvKn6f sYILC8PJ4Qzw6jS4Qpm4y1WHz8e/ElW6VyfmljZYA7f9WMntdfeQVqCVzNTvKn6f
hg6GSpJTzp4LV3ougi9nQuWXZF2wInsXkLYpsiMbL6Fz34RwohJtYA== hg6GSpJTzp4LV3ougi9nQuWXZF2wInsXkLYpsiMbL6Fz34RwohJtYA==
-----END RSA PRIVATE KEY----- -----END RSA PRIVATE KEY----- ]]></sourcecode>
]]></artwork> <t> Bob decrypts the key-derivation key with his RSA private key:</t>
</figure> <sourcecode type="test-vectors">
<![CDATA[ df85af9e3cebffde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde81eb
<t> Bob decrypts the key-derivation key with his RSA private key:</t> ]]></sourcecode>
<figure><artwork> <t>Bob produces a 256-bit key-encryption key with HKDF using SHA-384;
df85af9e3cebffde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde81eb the secret value is the key-derivation key; and the 'info' is
</artwork></figure> the DER-encoded CMSORIforPSKOtherInfo structure with the same
values as shown in <xref target="sect-a.1"/>. The HKDF output is 256 bits
<t>Bob produces a 256-bit key-encryption key with HKDF using SHA-384; the sec :</t>
ret value is the key-derivation key; the 'info' is the DER-encoded CMSORIforPSKO <sourcecode type="test-vectors"><![CDATA[
therInfo structure with the same values as shown in A.1. The HKDF output is 256 f319e9cebb35f1c6a7a9709b8760b9d0d3e30e16c5b2b69347e9f00ca540a232 ]]></sourcec
bits:</t> ode>
<figure><artwork> <t>Bob uses AES-KEY-WRAP to decrypt the content-encryption key with the
a14d87451dfd11d83cd54ffe2bd38c49a2adfed3ac49f1d3e62bbdc64ae43b32 key-encryption key; the content-encryption key is:</t>
</artwork></figure> <sourcecode type="test-vectors"><![CDATA[
c8adc30f4a3e20ac420caa76a68f5787c02ab42afea20d19672fd963a5338e83 ]]></sourcec
<t>Bob uses AES-KEY-WRAP to decrypt the content-encryption key with the key-e ode>
ncryption key; the content-encryption key is:</t> <t>Bob decrypts the content using AES-256-GCM with the content-encryptio
<figure><artwork> n key and checks the received authentication tag. The 12-octet nonce used is:</t
c8adc30f4a3e20ac420caa76a68f5787c02ab42afea20d19672fd963a5338e83 >
</artwork></figure> <sourcecode type="test-vectors">
<![CDATA[ cafebabefacedbaddecaf888 ]]></sourcecode>
<t>Bob decrypts the content using AES-256-GCM with the content-encryption key <t>The 12-octet authentication tag is: </t>
, and checks the received authentication tag. The 12-octet nonce used is:</t> <sourcecode type="test-vectors">
<figure><artwork> <![CDATA[ a0e5925cc184e0172463c44c ]]></sourcecode>
cafebabefacedbaddecaf888 <t>The received ciphertext content is:</t>
</artwork></figure> <sourcecode type="test-vectors">
<![CDATA[ 9af2d16f21547fcefed9b3ef2d ]]></sourcecode>
<t>The 12-octet authentication tag is: </t> <t>The resulting plaintext content is:</t>
<figure><artwork> <sourcecode type="test-vectors">
a0e5925cc184e0172463c44c <![CDATA[ 48656c6c6f2c20776f726c6421 ]]></sourcecode>
</artwork></figure> </section>
</section>
<t>The received ciphertext content is:</t> <section anchor="sect-b" numbered="true" toc="default">
<figure><artwork> <name>Key Agreement with PSK Example</name>
9af2d16f21547fcefed9b3ef2d <t>
</artwork></figure>
<t>The resulting plaintext content is:</t>
<figure><artwork>
48656c6c6f2c20776f726c6421
</artwork></figure>
</section>
</section>
<section title="Key Agreement with PSK Example" anchor="sect-b"><t>
This example shows the establishment of an AES-256 content-encryption This example shows the establishment of an AES-256 content-encryption
key using:</t> key using:</t>
<ul spacing="normal">
<li>a pre-shared key of 256 bits;</li>
<t><list style="symbols" hangIndent="3"> <li>key agreement using ECDH on curve P-384 and X9.63 KDF
<t>a pre-shared key of 256 bits;</t> with SHA-384;</li>
<t>key agreement using ECDH on curve P-384 and X9.63 KDF <li>key derivation using HKDF with SHA-384; and</li>
with SHA-384;</t> <li>key wrap using AES-256-KEYWRAP.</li>
<t>key derivation using HKDF with SHA-384; and</t> </ul>
<t>key wrap using AES-256-KEYWRAP.</t> <t>
</list>
</t>
<t>
In real-world use, the originator would treat themselves as an In real-world use, the originator would treat themselves as an
additional recipient by performing key agreement with their own additional recipient by performing key agreement with their own
static public key and the ephemeral private key generated for this static public key and the ephemeral private key generated for this
message. This is omitted in an attempt to simplify the example.</t> message. This is omitted in an attempt to simplify the example.</t>
<section anchor="sect-b.1" numbered="true" toc="default">
<section title="Originator Processing Example" anchor="sect-b.1"> <name>Originator Processing Example</name>
<t> The pre-shared key known to Alice and Bob, in hexadecimal, is:</t>
<t> The pre-shared key known to Alice and Bob, in hexadecimal:</t> <sourcecode type="test-vectors"><![CDATA[
<figure><artwork> 4aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c078660214e2d83e4 ]]></sourcec
4aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c078660214e2d83e4 ode>
</artwork></figure> <t>The identifier assigned to the pre-shared key is:</t>
<sourcecode type="test-vectors"><![CDATA[
<t>The identifier assigned to the pre-shared key is:</t> ptf-kmc:216840110121 ]]></sourcecode>
<figure><artwork> <t>Alice randomly generates a content-encryption key:</t>
ptf-kmc:216840110121 <sourcecode type="test-vectors"><![CDATA[
</artwork></figure> 937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033 ]]></sourcec
ode>
<t>Alice randomly generates a content-encryption key:</t> <t>Alice obtains Bob's static ECDH public key:</t>
<figure><artwork> <sourcecode type="test-vectors"><![CDATA[
937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033
</artwork></figure>
<t>Alice obtains Bob's static ECDH public key:</t>
<figure><artwork><![CDATA[
-----BEGIN PUBLIC KEY----- -----BEGIN PUBLIC KEY-----
MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEScGPBO9nmUwGrgbGEoFY9HR/bCo0WyeY MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEScGPBO9nmUwGrgbGEoFY9HR/bCo0WyeY
/dePQVrwZmwN2yMJmO2d1kWCvLTz8U7atinxyIRe9CV54yau1KWU/wbkhPDnzuSM /dePQVrwZmwN2yMJmO2d1kWCvLTz8U7atinxyIRe9CV54yau1KWU/wbkhPDnzuSM
YkcpxMGo32z3JetEloW5aFOja13vv/W5 YkcpxMGo32z3JetEloW5aFOja13vv/W5
-----END PUBLIC KEY----- -----END PUBLIC KEY----- ]]></sourcecode>
]]></artwork> <t>It has a key identifier of:</t>
</figure> <sourcecode type="test-vectors"><![CDATA[
e8218b98b8b7d86b5e9ebdc8aeb8c4ecdc05c529 ]]></sourcecode>
<t>It has a key identifier of:</t> <t> Alice generates an ephemeral ECDH key pair on the same curve:</t>
<figure><artwork> <sourcecode type="test-vectors"><![CDATA[
e8218b98b8b7d86b5e9ebdc8aeb8c4ecdc05c529
</artwork></figure>
<t> Alice generates an ephemeral ECDH key pair on the same curve:</t>
<figure><artwork><![CDATA[
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDCMiWLG44ik+L8cYVvJrQdLcFA+PwlgRF+Wt1Ab25qUh8OB7OePWjxp MIGkAgEBBDCMiWLG44ik+L8cYVvJrQdLcFA+PwlgRF+Wt1Ab25qUh8OB7OePWjxp
/b8P6IOuI6GgBwYFK4EEACKhZANiAAQ5G0EmJk/2ks8sXY1kzbuG3Uu3ttWwQRXA /b8P6IOuI6GgBwYFK4EEACKhZANiAAQ5G0EmJk/2ks8sXY1kzbuG3Uu3ttWwQRXA
LFDJICjvYfr+yTpOQVkchm88FAh9MEkw4NKctokKNgpsqXyrT3DtOg76oIYENpPb LFDJICjvYfr+yTpOQVkchm88FAh9MEkw4NKctokKNgpsqXyrT3DtOg76oIYENpPb
GE5lJdjPx9sBsZQdABwlsU0Zb7P/7i8= GE5lJdjPx9sBsZQdABwlsU0Zb7P/7i8=
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY----- ]]></sourcecode>
]]></artwork> <t>Alice computes a shared secret called "Z" using Bob's static ECDH
</figure>
<t>Alice computes a shared secret, called Z, using the Bob's static ECDH
public key and her ephemeral ECDH private key; Z is: </t> public key and her ephemeral ECDH private key; Z is: </t>
<figure><artwork> <sourcecode type="test-vectors"><![CDATA[
3f015ed0ff4b99523a95157bbe77e9cc0ee52fcffeb7e41eac79d1c11b6cc556 3f015ed0ff4b99523a95157bbe77e9cc0ee52fcffeb7e41eac79d1c11b6cc556
19cf8807e6d800c2de40240fe0e26adc 19cf8807e6d800c2de40240fe0e26adc ]]></sourcecode>
</artwork></figure> <t> Alice computes the pairwise key-encryption key, called "KEK1", from
Z using
<t> Alice computes the pairwise key-encryption key, called KEK1, from Z using
the X9.63 KDF with the ECC-CMS-SharedInfo structure with the following values: the X9.63 KDF with the ECC-CMS-SharedInfo structure with the following values:
</t> </t>
<sourcecode type="test-vectors"><![CDATA[
<figure><artwork><![CDATA[ 0 21: SEQUENCE {
0 21: SEQUENCE { 2 11: SEQUENCE {
2 11: SEQUENCE { 4 9: OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45)
4 9: OBJECT IDENTIFIER aes256-wrap : }
: { 2 16 840 1 101 3 4 1 45 } 15 6: [2] {
: } 17 4: OCTET STRING 00 00 00 20
15 6: [2] { : }
17 4: OCTET STRING 00 00 00 20 : } ]]></sourcecode>
: } <t>The DER encoding of ECC-CMS-SharedInfo produces 23 octets:</t>
: } <sourcecode type="test-vectors"><![CDATA[
]]></artwork> 3015300b060960864801650304012da206040400000020 ]]></sourcecode>
</figure> <t>The X9.63 KDF output is the 256-bit KEK1:</t>
<sourcecode type="test-vectors"><![CDATA[
<t>The DER encoding of ECC-CMS-SharedInfo produces 23 octets:</t> 27dc25ddb0b425f7a968ceada80a8f73c6ccaab115baafcce4a22a45d6b8f3da ]]></source
<figure><artwork> code>
3015300b060960864801650304012da206040400000020 <t>Alice produces the 256-bit KEK2 with HKDF using SHA-384; the secret
</artwork></figure> value is KEK1; and the 'info' is the DER-encoded CMSORIforPSKOtherInfo
<t>The X9.63 KDF output is the 256-bit KEK1:</t>
<figure><artwork>
27dc25ddb0b425f7a968ceada80a8f73c6ccaab115baafcce4a22a45d6b8f3da
</artwork></figure>
<t>Alice produces the 256-bit KEK2 with HKDF using SHA-384; the secret
value is KEK1; the 'info' is the DER-encoded CMSORIforPSKOtherInfo
structure with the following values:</t> structure with the following values:</t>
<sourcecode type="test-vectors"><![CDATA[
<figure><artwork><![CDATA[ 0 56: SEQUENCE {
0 56: SEQUENCE { 2 32: OCTET STRING
2 32: OCTET STRING : 4A A5 3C BF 50 08 50 DD 58 3A 5D 98 21 60 5C 6F
: 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
: A2 28 FB 59 17 F8 7C 1C 07 86 60 21 4E 2D 83 E4 36 1: ENUMERATED 10
36 1: ENUMERATED 10 39 11: SEQUENCE {
39 11: SEQUENCE { 41 9: OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45)
41 9: OBJECT IDENTIFIER aes256-wrap : }
: { 2 16 840 1 101 3 4 1 45 } 52 1: INTEGER 32
: } 55 1: INTEGER 32
52 1: INTEGER 32 : } ]]></sourcecode>
55 1: INTEGER 32 <t>The DER encoding of CMSORIforPSKOtherInfo produces 58 octets:</t>
: } <sourcecode type="test-vectors"><![CDATA[
]]></artwork>
</figure>
<t>The DER encoding of CMSORIforPSKOtherInfo produces 58 octets:</t>
<figure><artwork>
303804204aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c07866021 303804204aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c07866021
4e2d83e40a010a300b060960864801650304012d020120020120 4e2d83e40a010a300b060960864801650304012d020120020120 ]]></sourcecode>
</artwork></figure> <t>The HKDF output is the 256-bit KEK2:</t>
<sourcecode type="test-vectors"><![CDATA[
<t>The HKDF output is the 256-bit KEK2:</t> 7de693ee30ae22b5f8f6cd026c2164103f4e1430f1ab135dc1fb98954f9830bb ]]></source
<figure><artwork> code>
7de693ee30ae22b5f8f6cd026c2164103f4e1430f1ab135dc1fb98954f9830bb <t>Alice uses AES-KEY-WRAP to encrypt the content-encryption key with th
</artwork></figure> e KEK2; the wrapped key is:</t>
<sourcecode type="test-vectors"><![CDATA[
<t>Alice uses AES-KEY-WRAP to encrypt the content-encryption key with the KEK
2; the wrapped key is:</t>
<figure><artwork>
229fe0b45e40003e7d8244ec1b7e7ffb2c8dca16c36f5737222553a71263a92b 229fe0b45e40003e7d8244ec1b7e7ffb2c8dca16c36f5737222553a71263a92b
de08866a602d63f4 de08866a602d63f4 ]]></sourcecode>
</artwork></figure> <t>Alice encrypts the content using AES-256-GCM with the content-encrypt
ion key. The 12-octet nonce used is:</t>
<t>Alice encrypts the content using AES-256-GCM with the content-encryption k <sourcecode type="test-vectors"><![CDATA[
ey. The 12-octet nonce used is:</t> dbaddecaf888cafebabeface ]]></sourcecode>
<figure><artwork> <t>The plaintext is:</t>
dbaddecaf888cafebabeface <sourcecode type="test-vectors"><![CDATA[
</artwork></figure> 48656c6c6f2c20776f726c6421 ]]></sourcecode>
<t>The resulting ciphertext is:</t>
<t>The plaintext is:</t> <sourcecode type="test-vectors"><![CDATA[
<figure><artwork> fc6d6f823e3ed2d209d0c6ffcf ]]></sourcecode>
48656c6c6f2c20776f726c6421 <t>The resulting 12-octet authentication tag is:</t>
</artwork></figure> <sourcecode type="test-vectors"><![CDATA[
550260c42e5b29719426c1ff ]]></sourcecode>
<t>The resulting ciphertext is:</t> </section>
<figure><artwork> <section anchor="sect-b.2" numbered="true" toc="default">
fc6d6f823e3ed2d209d0c6ffcf <name>ContentInfo and AuthEnvelopedData</name>
</artwork></figure> <t>
Alice encodes the AuthEnvelopedData and the ContentInfo and
<t>The resulting 12-octet authentication tag is:</t>
<figure><artwork>
550260c42e5b29719426c1ff
</artwork></figure>
</section>
<section title="ContentInfo and AuthEnvelopedData" anchor="sect-b.2"><t>
Alice encodes the AuthEnvelopedData and the ContentInfo, and
sends the result to Bob. The resulting structure is:</t> sends the result to Bob. The resulting structure is:</t>
<sourcecode type="test-vectors"><![CDATA[
<figure><artwork><![CDATA[
0 327: SEQUENCE { 0 327: SEQUENCE {
4 11: OBJECT IDENTIFIER authEnvelopedData 4 11: OBJECT IDENTIFIER
: { 1 2 840 113549 1 9 16 1 23 } : authEnvelopedData (1 2 840 113549 1 9 16 1 23)
17 310: [0] { 17 310: [0] {
21 306: SEQUENCE { 21 306: SEQUENCE {
25 1: INTEGER 0 25 1: INTEGER 0
28 229: SET { 28 229: SET {
31 226: [4] { 31 226: [4] {
34 11: OBJECT IDENTIFIER ** Placeholder ** 34 11: OBJECT IDENTIFIER
: { 1 2 840 113549 1 9 16 TBD 2 } : keyAgreePSK (1 2 840 113549 1 9 16 13 2)
47 210: SEQUENCE { 47 210: SEQUENCE {
50 1: INTEGER 0 50 1: INTEGER 0
53 20: OCTET STRING 'ptf-kmc:216840110121' 53 20: OCTET STRING 'ptf-kmc:216840110121'
75 85: [0] { 75 85: [0] {
77 83: [1] { 77 83: [1] {
79 19: SEQUENCE { 79 19: SEQUENCE {
81 6: OBJECT IDENTIFIER 81 6: OBJECT IDENTIFIER
: dhSinglePass-stdDH-sha256kdf-scheme : ecdhX963KDF-SHA256 (1 3 132 1 11 1)
: { 1 3 132 1 11 1 } 89 9: OBJECT IDENTIFIER
89 9: OBJECT IDENTIFIER aes256-wrap : aes256-wrap (2 16 840 1 101 3 4 1 45)
: { 2 16 840 1 101 3 4 1 45 } : }
: }
100 60: BIT STRING, encapsulates { 100 60: BIT STRING, encapsulates {
103 57: OCTET STRING 103 57: OCTET STRING
: 1B 41 26 26 4F F6 92 CF 2C 5D 8D 64 CD BB 86 DD : 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 : 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 : 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 : E0 D2 9C B6 89 0A 36 0A 6C
: } : }
: } : }
: } : }
162 13: SEQUENCE { 162 13: SEQUENCE {
164 11: OBJECT IDENTIFIER ** Placeholder ** 164 11: OBJECT IDENTIFIER
: { 1 2 840 113549 1 9 16 3 TBD } : hkdf-with-sha384 (1 2 840 113549 1 9 16 3 29)
: } : }
177 11: SEQUENCE { 177 11: SEQUENCE {
179 9: OBJECT IDENTIFIER aes256-wrap 179 9: OBJECT IDENTIFIER
: { 2 16 840 1 101 3 4 1 45 } : aes256-wrap (2 16 840 1 101 3 4 1 45)
: } : }
190 68: SEQUENCE { 190 68: SEQUENCE {
192 66: SEQUENCE { 192 66: SEQUENCE {
194 22: [0] { 194 22: [0] {
196 20: OCTET STRING 196 20: OCTET STRING
: E8 21 8B 98 B8 B7 D8 6B 5E 9E BD C8 AE B8 C4 EC : E8 21 8B 98 B8 B7 D8 6B 5E 9E BD C8 AE B8 C4 EC
: DC 05 C5 29 : DC 05 C5 29
: } : }
218 40: OCTET STRING 218 40: OCTET STRING
: 22 9F E0 B4 5E 40 00 3E 7D 82 44 EC 1B 7E 7F FB : 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 : 2C 8D CA 16 C3 6F 57 37 22 25 53 A7 12 63 A9 2B
: DE 08 86 6A 60 2D 63 F4 : DE 08 86 6A 60 2D 63 F4
: } : }
: } : }
: } : }
: } : }
: } : }
260 55: SEQUENCE { 260 55: SEQUENCE {
262 9: OBJECT IDENTIFIER data { 1 2 840 113549 1 7 1 } 262 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
273 27: SEQUENCE { 273 27: SEQUENCE {
275 9: OBJECT IDENTIFIER aes256-GCM 275 9: OBJECT IDENTIFIER
: { 2 16 840 1 101 3 4 1 46 } : aes256-GCM (2 16 840 1 101 3 4 1 46)
286 14: SEQUENCE { 286 14: SEQUENCE {
288 12: OCTET STRING DB AD DE CA F8 88 CA FE BA BE FA CE 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
: } : }
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 317 12: OCTET STRING 55 02 60 C4 2E 5B 29 71 94 26 C1 FF
: }
: } : }
: } : } ]]></sourcecode>
: } </section>
]]></artwork>
</figure>
</section>
<section title="Recipient Processing Example" anchor="sect-b.3">
<t> Bob obtains Alice's ephemeral ECDH public key from the message:</t>
<figure><artwork><![CDATA[ <section anchor="sect-b.3" numbered="true" toc="default">
<name>Recipient Processing Example</name>
<t> Bob obtains Alice's ephemeral ECDH public key from the message:</t>
<sourcecode type="test-vectors"><![CDATA[
-----BEGIN PUBLIC KEY----- -----BEGIN PUBLIC KEY-----
MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEORtBJiZP9pLPLF2NZM27ht1Lt7bVsEEV MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEORtBJiZP9pLPLF2NZM27ht1Lt7bVsEEV
wCxQySAo72H6/sk6TkFZHIZvPBQIfTBJMODSnLaJCjYKbKl8q09w7ToO+qCGBDaT wCxQySAo72H6/sk6TkFZHIZvPBQIfTBJMODSnLaJCjYKbKl8q09w7ToO+qCGBDaT
2xhOZSXYz8fbAbGUHQAcJbFNGW+z/+4v 2xhOZSXYz8fbAbGUHQAcJbFNGW+z/+4v
-----END PUBLIC KEY----- -----END PUBLIC KEY----- ]]></sourcecode>
]]></artwork> <t> Bob's static ECDH private key is:</t>
</figure> <sourcecode type="test-vectors"><![CDATA[
<t> Bob's static ECDH private key:</t>
<figure><artwork><![CDATA[
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDAnJ4hB+tTUN9X03/W0RsrYy+qcptlRSYkhaDIsQYPXfTU0ugjJEmRk MIGkAgEBBDAnJ4hB+tTUN9X03/W0RsrYy+qcptlRSYkhaDIsQYPXfTU0ugjJEmRk
NTPj4y1IRjegBwYFK4EEACKhZANiAARJwY8E72eZTAauBsYSgVj0dH9sKjRbJ5j9 NTPj4y1IRjegBwYFK4EEACKhZANiAARJwY8E72eZTAauBsYSgVj0dH9sKjRbJ5j9
149BWvBmbA3bIwmY7Z3WRYK8tPPxTtq2KfHIhF70JXnjJq7UpZT/BuSE8OfO5Ixi 149BWvBmbA3bIwmY7Z3WRYK8tPPxTtq2KfHIhF70JXnjJq7UpZT/BuSE8OfO5Ixi
RynEwajfbPcl60SWhbloU6NrXe+/9bk= RynEwajfbPcl60SWhbloU6NrXe+/9bk=
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY----- ]]></sourcecode>
]]></artwork> <t> Bob computes a shared secret called "Z" using Alice's ephemeral
</figure>
<t> Bob computes a shared secret, called Z, using the Alice's ephemeral
ECDH public key and his static ECDH private key; Z is:</t> ECDH public key and his static ECDH private key; Z is:</t>
<figure><artwork> <sourcecode type="test-vectors"><![CDATA[
3f015ed0ff4b99523a95157bbe77e9cc0ee52fcffeb7e41eac79d1c11b6cc556 3f015ed0ff4b99523a95157bbe77e9cc0ee52fcffeb7e41eac79d1c11b6cc556
19cf8807e6d800c2de40240fe0e26adc 19cf8807e6d800c2de40240fe0e26adc ]]></sourcecode>
</artwork></figure> <t> Bob computes the pairwise key-encryption key, KEK1, from Z using
<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 the X9.63 KDF with the ECC-CMS-SharedInfo structure with the values shown
in B.1. The X9.63 KDF output is the 256-bit KEK1:</t> in <xref target="sect-b.1"/>. The X9.63 KDF output is the 256-bit KEK1:</t>
<figure><artwork> <sourcecode type="test-vectors"><![CDATA[
27dc25ddb0b425f7a968ceada80a8f73c6ccaab115baafcce4a22a45d6b8f3da 27dc25ddb0b425f7a968ceada80a8f73c6ccaab115baafcce4a22a45d6b8f3da ]]></sourc
</artwork></figure> ecode>
<t>Bob produces the 256-bit KEK2 with HKDF using SHA-384; the secret v
<t>Bob produces the 256-bit KEK2 with HKDF using SHA-384; the secret v alue
alue is KEK1; and the 'info' is the DER-encoded CMSORIforPSKOtherInfo structure wi
is KEK1; the 'info' is the DER-encoded CMSORIforPSKOtherInfo structure with th
the values shown in B.1. The HKDF output is the 256-bit KEK2:</t> the values shown in <xref target="sect-b.1"/>. The HKDF output is the 256-bi
<figure><artwork> t KEK2:</t>
7de693ee30ae22b5f8f6cd026c2164103f4e1430f1ab135dc1fb98954f9830bb <sourcecode type="test-vectors"><![CDATA[
</artwork></figure> 7de693ee30ae22b5f8f6cd026c2164103f4e1430f1ab135dc1fb98954f9830bb ]]></sourcec
ode>
<t> Bob uses AES-KEY-WRAP to decrypt the content-encryption key with the <t> Bob uses AES-KEY-WRAP to decrypt the content-encryption key with the
KEK2; the content-encryption key is: </t> KEK2; the content-encryption key is: </t>
<figure><artwork> <sourcecode type="test-vectors"><![CDATA[
937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033 937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033 ]]></sourc
</artwork></figure> ecode>
<t>Bob decrypts the content using AES-256-GCM with the content-encryptio
<t>Bob decrypts the content using AES-256-GCM with the content-encryption n
key, and checks the received authentication tag. The 12-octet nonce used is: key and checks the received authentication tag. The 12-octet nonce used is:<
</t> /t>
<figure><artwork> <sourcecode type="test-vectors"><![CDATA[
dbaddecaf888cafebabeface dbaddecaf888cafebabeface ]]></sourcecode>
</artwork></figure> <t>The 12-octet authentication tag is:</t>
<sourcecode type="test-vectors"><![CDATA[
<t>The 12-octet authentication tag is:</t> 550260c42e5b29719426c1ff ]]></sourcecode>
<figure><artwork> <t>The received ciphertext content is:</t>
550260c42e5b29719426c1ff <sourcecode type="test-vectors"><![CDATA[
</artwork></figure> fc6d6f823e3ed2d209d0c6ffcf ]]></sourcecode>
<t>The resulting plaintext content is:</t>
<t>The received ciphertext content is:</t> <sourcecode type="test-vectors"><![CDATA[
<figure><artwork> 48656c6c6f2c20776f726c6421 ]]></sourcecode>
fc6d6f823e3ed2d209d0c6ffcf </section>
</artwork></figure> </section>
<section numbered="false" anchor="acknowledgements" toc="default">
<t>The resulting plaintext content is:</t> <name>Acknowledgements</name>
<figure><artwork> <t>
48656c6c6f2c20776f726c6421
</artwork></figure>
</section>
</section>
<section title="Acknowledgements" numbered="no" anchor="acknowledgements"
><t>
Many thanks to Roman Danyliw, Ben Kaduk, Burt Kaliski, Panos Many thanks to Roman Danyliw, Ben Kaduk, Burt Kaliski, Panos
Kampanakis, Jim Schaad, Robert Sparks, Sean Turner, and Daniel Van Kampanakis, Jim Schaad, Robert Sparks, Sean Turner, and Daniel Van
Geest for their review and insightful comments. They have greatly Geest for their review and insightful comments. They have greatly
improved the design, clarity, and implementation guidance.</t> improved the design, clarity, and implementation guidance.</t>
</section>
</back>
</section> </rfc>
</back>
</rfc>
 End of changes. 190 change blocks. 
1195 lines changed or deleted 919 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/