Using PreShared Key (PSK) in the Cryptographic Message Syntax (CMS)
Vigil Security, LLC
516 Dranesville Road
Herndon
VA
20170
United States of America
housley@vigilsec.com
The invention of a largescale quantum computer would pose a serious
challenge for the cryptographic algorithms that are widely deployed
today. The Cryptographic Message Syntax (CMS) supports key transport
and key agreement algorithms that could be broken by the invention of
such a quantum computer. By storing communications that are
protected with the CMS today, someone could decrypt them in the
future when a largescale quantum computer becomes available. Once
quantumsecure key management algorithms are available, the CMS will
be extended to support the new algorithms if the existing syntax
does not accommodate them. This document describes
a mechanism to protect today's communication from the future
invention of a largescale quantum computer by mixing the output of
key transport and key agreement algorithms with a preshared key.
Introduction
The invention of a largescale quantum computer would pose a serious
challenge for the cryptographic algorithms that are widely deployed
today . It is an open question whether or not it is feasible
to build a largescale quantum computer and, if so, when that might
happen . However, if such a quantum computer is invented,
many of the cryptographic algorithms and the security protocols that
use them would become vulnerable.
The Cryptographic Message Syntax (CMS) supports
key transport and key agreement algorithms that could be broken by
the invention of a largescale quantum computer . These
algorithms include RSA , DiffieHellman , and
Elliptic Curve DiffieHellman (ECDH) . As a result, an adversary
that stores CMSprotected communications today could decrypt those
communications in the future when a largescale quantum computer
becomes available.
Once quantumsecure key management algorithms are available, the CMS
will be extended to support them if the existing syntax does not
already accommodate the new algorithms.
In the near term, this document describes a mechanism to protect
today's communication from the future invention of a largescale
quantum computer by mixing the output of existing key transport and
key agreement algorithms with a preshared key (PSK). Secure
communication can be achieved today by mixing a strong PSK with the
output of an existing key transport algorithm, like RSA , or
an existing key agreement algorithm, like DiffieHellman or
Elliptic Curve DiffieHellman (ECDH) . A
security solution that is
believed to be quantum resistant can be achieved by using a PSK with
sufficient entropy along with a quantumresistant key derivation
function (KDF), like an HMACbased key derivation function
(HKDF) , and a quantumresistant
encryption algorithm, like 256bit AES . In this way, today's
CMSprotected communication can be resistant to an attacker with a
largescale quantum computer.
In addition, there may be other reasons for including a strong PSK
besides protection against the future invention of a largescale
quantum computer. For example, there is always the possibility of a
cryptoanalytic breakthrough on one or more classic public key
algorithms, and there are longstanding concerns about undisclosed
trapdoors in DiffieHellman parameters . Inclusion of a
strong PSK as part of the overall key management offers additional
protection against these concerns.
Note that the CMS also supports key management techniques based on
symmetric keyencryption keys and passwords, but they are not
discussed in this document because they are already quantum
resistant. The symmetric keyencryption key technique is quantum
resistant when used with an adequate key size. The password
technique is quantum resistant when used with a quantumresistant key
derivation function and a sufficiently large password.
Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
ASN.1
CMS values are generated using ASN.1 , which uses the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER)
.
Version Numbers
The major data structures include a version number as the first item
in the data structure. The version number is intended to avoid ASN.1
decode errors. Some implementations do not check the version number
prior to attempting a decode; then, if a decode error occurs, the
version number is checked as part of the errorhandling routine.
This is a reasonable approach; it places error processing outside of
the fast path. This approach is also forgiving when an incorrect
version number is used by the sender.
Whenever the structure is updated, a higher version number will be
assigned. However, to ensure maximum interoperability, the higher
version number is only used when the new syntax feature is employed.
That is, the lowest version number that supports the generated syntax
is used.
Overview
The CMS envelopeddata content type and the CMS
authenticatedenvelopeddata content type support both key
transport and key agreement public key algorithms to establish the
key used to encrypt the content. No restrictions are imposed on the
key transport or key agreement public key algorithms, which means
that any key transport or key agreement algorithm can be used,
including algorithms that are specified in the future. In both
cases, the sender randomly generates the contentencryption key, and
then all recipients obtain that key. All recipients use the sendergenerated symmetric contentencryption key for decryption.
This specification defines two quantumresistant ways to establish a
symmetric keyencryption key, which is used to encrypt the sendergenerated contentencryption key. In both cases, the PSK is used as
one of the inputs to a keyderivation function to create a quantumresistant keyencryption key. The PSK MUST be distributed to the
sender and all of the recipients by some outofband means that does
not make it vulnerable to the future invention of a largescale
quantum computer, and an identifier MUST be assigned to the PSK. It
is best if each PSK has a unique identifier; however, if a recipient
has more than one PSK with the same identifier, the recipient can try
each of them in turn. A PSK is expected to be used with many
messages, with a lifetime of weeks or months.
The contentencryption key or contentauthenticatedencryption key is
quantum resistant, and the sender establishes it using these steps:
When using a key transport algorithm:
 The contentencryption key or the
contentauthenticatedencryption key, called "CEK", is generated at random.
 The keyderivation key, called "KDK", is generated at random.
 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
keyencryption key, called "KEK".
 The KEK is used to encrypt the CEK.
When using a key agreement algorithm:
 The contentencryption key or the
contentauthenticatedencryption key, called "CEK", is generated at random.
 For each recipient, a pairwise keyencryption 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 keyderivation key.
 For each recipient, the KDF is used
to mix the PSK and the pairwise KEK1, and the
result is called "KEK2".
 For each recipient, the pairwise KEK2 is used to encrypt the
CEK.
As specified in , recipient information for
additional key management techniques is represented in the
OtherRecipientInfo type. Two key management techniques are specified
in this document, and they are each identified by a unique ASN.1
object identifier.
The first key management technique, called "keyTransPSK" (see
), uses a key transport algorithm to transfer the keyderivation key from the sender to the recipient, and then the keyderivation key is mixed with the PSK using a KDF. The output of the
KDF is the keyencryption key, which is used for the encryption of
the contentencryption key or contentauthenticatedencryption key.
The second key management technique, called "keyAgreePSK" (see
), uses a key agreement algorithm to establish a pairwise keyencryption
key. This pairwise keyencryption key is then mixed with the PSK using a
KDF to produce a second pairwise keyencryption key, which is then used to
encrypt the contentencryption key or contentauthenticatedencryption key.
keyTransPSK
Perrecipient information using keyTransPSK is represented in the
KeyTransPSKRecipientInfo type, which is indicated by the idorikeyTransPSK object identifier. Each instance of
KeyTransPSKRecipientInfo establishes the contentencryption key or
contentauthenticatedencryption key for one or more recipients that
have access to the same PSK.
The idorikeyTransPSK object identifier is:
The KeyTransPSKRecipientInfo type is:
The fields of the KeyTransPSKRecipientInfo type have the following
meanings:

version is the syntax version number. The version MUST be 0. The
CMSVersion type is described in .

pskid is the identifier of the PSK used by the sender. The
identifier is an OCTET STRING, and it need not be human readable.

kdfAlgorithm identifies the keyderivation algorithm and any associated parameters used by the sender to mix the keyderivation key and the PSK to generate the keyencryption key.
The KeyDerivationAlgorithmIdentifier is described in .

keyEncryptionAlgorithm identifies a keyencryption algorithm used
to encrypt the contentencryption key. The
KeyEncryptionAlgorithmIdentifier is described in .

ktris contains one KeyTransRecipientInfo type for each recipient;
it uses a key transport algorithm to establish the keyderivation
key. That is, the encryptedKey field of KeyTransRecipientInfo
contains the keyderivation key instead of the contentencryption
key. KeyTransRecipientInfo is described in .

encryptedKey is the result of encrypting the contentencryption
key or the contentauthenticatedencryption key with the keyencryption key. EncryptedKey is an OCTET STRING.
keyAgreePSK
Perrecipient information using keyAgreePSK is represented in the
KeyAgreePSKRecipientInfo type, which is indicated by the idorikeyAgreePSK object identifier. Each instance of
KeyAgreePSKRecipientInfo establishes the contentencryption key or
contentauthenticatedencryption key for one or more recipients that
have access to the same PSK.
The idorikeyAgreePSK object identifier is:
The fields of the KeyAgreePSKRecipientInfo type have the following meanings:

version is the syntax version number. The version MUST be 0. The
CMSVersion type is described in .

pskid is the identifier of the PSK used by the sender. The
identifier is an OCTET STRING, and it need not be human readable.

originator is a CHOICE with three alternatives specifying the
sender's key agreement public key. Implementations MUST support
all three alternatives for specifying the sender's public key.
The sender uses their own private key and the recipient's public
key to generate a pairwise keyencryption key. A KDF
is used to mix the PSK and the pairwise keyencryption key to produce a second keyencryption key. The
OriginatorIdentifierOrKey type is described in .

ukm is optional. With some key agreement algorithms, the sender
provides a User Keying Material (UKM) to ensure that a different
key is generated each time the same two parties generate a
pairwise key. Implementations MUST accept a
KeyAgreePSKRecipientInfo SEQUENCE that includes a ukm field.
Implementations that do not support key agreement algorithms that
make use of UKMs MUST gracefully handle the presence of UKMs. The
UserKeyingMaterial type is described in .

kdfAlgorithm identifies the keyderivation algorithm and any
associated parameters used by the sender to mix the pairwise keyencryption key and the PSK to produce a second keyencryption key
of the same length as the first one. The
KeyDerivationAlgorithmIdentifier is described in .

keyEncryptionAlgorithm identifies a keyencryption algorithm used
to encrypt the contentencryption key or the contentauthenticatedencryption key. The
KeyEncryptionAlgorithmIdentifier type is described in .

recipientEncryptedKeys includes a recipient identifier and
encrypted key for one or more recipients. The
KeyAgreeRecipientIdentifier is a CHOICE with two alternatives
specifying the recipient's certificate, and thereby the
recipient's public key, that was used by the sender to generate a
pairwise keyencryption key. The encryptedKey is the result of
encrypting the contentencryption key or the contentauthenticatedencryption key with the second pairwise keyencryption key. EncryptedKey is an OCTET STRING. The
RecipientEncryptedKeys type is defined in .
Key Derivation
Many KDFs internally employ a oneway hash
function. When this is the case, the hash function that is used is
indirectly indicated by the KeyDerivationAlgorithmIdentifier. HKDF
is one example of a KDF that makes use of a hash function.
Other KDFs internally employ an encryption algorithm. When this is
the case, the encryption that is used is indirectly indicated by the
KeyDerivationAlgorithmIdentifier. For example, AES128CMAC can be
used for randomness extraction in a KDF as described in .
A KDF has several input values. This section describes the
conventions for using the KDF to compute the keyencryption key for
KeyTransPSKRecipientInfo and KeyAgreePSKRecipientInfo. For
simplicity, the terminology used in the HKDF specification is used here.
The KDF inputs are:
 IKM is the input keying material; it is the symmetric secret input
to the KDF. For KeyTransPSKRecipientInfo, it is the keyderivation key. For KeyAgreePSKRecipientInfo, it is the pairwise
keyencryption key produced by the key agreement algorithm.
 salt is an optional nonsecret random value. Many KDFs do not
require a salt, and the KeyDerivationAlgorithmIdentifier
assignments for HKDF do not offer a parameter for a
salt. If a particular KDF requires a salt, then the salt value is
provided as a parameter of the KeyDerivationAlgorithmIdentifier.
 L is the length of output keying material in octets; the value
depends on the keyencryption algorithm that will be used. The
algorithm is identified by the KeyEncryptionAlgorithmIdentifier.
In addition, the OBJECT IDENTIFIER portion of the
KeyEncryptionAlgorithmIdentifier is included in the next input
value, called "info".
 info is optional context and application specific information.
The DER encoding of CMSORIforPSKOtherInfo is used as the info
value, and the PSK is included in this structure. Note that
EXPLICIT tagging is used in the ASN.1 module that defines this
structure. For KeyTransPSKRecipientInfo, the ENUMERATED value of
5 is used. For KeyAgreePSKRecipientInfo, the ENUMERATED value of
10 is used. CMSORIforPSKOtherInfo is defined by the following
ASN.1 structure:
The fields of type CMSORIforPSKOtherInfo have the following
meanings:

psk is an OCTET STRING; it contains the PSK.

keyMgmtAlgType is either set to 5 or 10. For
KeyTransPSKRecipientInfo, the ENUMERATED value of 5 is used. For
KeyAgreePSKRecipientInfo, the ENUMERATED value of 10 is used.

keyEncryptionAlgorithm is the KeyEncryptionAlgorithmIdentifier,
which identifies the algorithm and provides algorithm parameters,
if any.

pskLength is a positive integer; it contains the length of the PSK
in octets.

kdkLength is a positive integer; it contains the length of the
keyderivation key in octets. For KeyTransPSKRecipientInfo, the
keyderivation key is generated by the sender. For
KeyAgreePSKRecipientInfo, the keyderivation key is the pairwise
keyencryption key produced by the key agreement algorithm.
The KDF output is:

OKM is the output keying material, which is exactly L octets. The
OKM is the keyencryption key that is used to encrypt the contentencryption key or the contentauthenticatedencryption key.
An acceptable KDF MUST accept IKM, L, and info inputs; an acceptable
KDF MAY also accept salt and other inputs. All of these inputs MUST
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
KeyDerivationAlgorithmIdentifier.
ASN.1 Module
This section contains the ASN.1 module for the two key management
techniques defined in this document. This module imports types from
other ASN.1 modules that are defined in and .
Security Considerations
The security considerations related to the CMS envelopeddata
content type in and the security considerations related to
the CMS authenticatedenvelopeddata content type in
continue to apply.
Implementations of the key derivation function must compute the
entire result, which, in this specification, is a keyencryption key,
before outputting any portion of the result. The resulting keyencryption key must be protected. Compromise of the keyencryption
key may result in the disclosure of all contentencryption keys or
contentauthenticatedencryption keys that were protected with that
keying material; this, in turn, may result in the disclosure of the
content. Note that there are two keyencryption keys when a PSK with
a key agreement algorithm is used, with similar consequences for the
compromise of either one of these keys.
Implementations must protect the PSK, key transport
private key, agreement private key, and keyderivation key.
Compromise of the PSK will make the encrypted content vulnerable to
the future invention of a largescale quantum computer. Compromise
of the PSK and either the key transport private key or the agreement
private key may result in the disclosure of all contents protected
with that combination of keying material. Compromise of the PSK and
the keyderivation key may result in the disclosure of all contents
protected with that combination of keying material.
A largescale quantum computer will essentially negate the security
provided by the key transport algorithm or the key agreement
algorithm, which means that the attacker with a largescale quantum
computer can discover the keyderivation key. In addition, a largescale quantum computer effectively cuts the security provided by a
symmetric key algorithm in half. Therefore, the PSK needs at least
256 bits of entropy to provide 128 bits of security. To match that
same level of security, the key derivation function needs to be
quantum resistant and produce a keyencryption key that is at least
256 bits in length. Similarly, the contentencryption key or
contentauthenticatedencryption key needs to be at least 256 bits in
length.
When using a PSK with a key transport or a key agreement algorithm, a
keyencryption key is produced to encrypt the contentencryption key
or contentauthenticatedencryption key. If the keyencryption
algorithm is different than the algorithm used to protect the
content, then the effective security is determined by the weaker of
the two algorithms. If, for example, content is encrypted with
256bit AES and the key is wrapped with 128bit AES, then, at most, 128 bits of protection are provided. Implementers must ensure that
the keyencryption algorithm is as strong or stronger than the
contentencryption algorithm or contentauthenticatedencryption
algorithm.
The selection of the keyderivation function imposes an upper bound
on the strength of the resulting keyencryption key. The strength of
the selected keyderivation function should be at least as strong as
the keyencryption algorithm that is selected. NIST SP 80056C
Revision 1 offers advice on the security strength of
several popular keyderivation functions.
Implementers should not mix quantumresistant key management
algorithms with their nonquantumresistant counterparts. For
example, the same content should not be protected with
KeyTransRecipientInfo and KeyTransPSKRecipientInfo. Likewise, the
same content should not be protected with KeyAgreeRecipientInfo and
KeyAgreePSKRecipientInfo. Doing so would make the content vulnerable
to the future invention of a largescale quantum computer.
Implementers should not send the same content in different messages,
one using a quantumresistant key management algorithm and the other
using a nonquantumresistant key management algorithm, even if the
contentencryption key is generated independently. Doing so may
allow an eavesdropper to correlate the messages, making the content
vulnerable to the future invention of a largescale quantum computer.
This specification does not require that PSK be known only by the
sender and recipients. The PSK may be known to a group. Since
confidentiality depends on the key transport or key agreement
algorithm, knowledge of the PSK by other parties does not inherently enable
eavesdropping. However, group members can record the
traffic of other members and then decrypt it if they ever gain
access to a largescale quantum computer. Also, when many parties
know the PSK, there are many opportunities for theft of the PSK by an
attacker. Once an attacker has the PSK, they can decrypt stored
traffic if they ever gain access to a largescale quantum computer in
the same manner as a legitimate group member.
Sound cryptographic key hygiene is to use a key for one and only one
purpose. Use of the recipient's public key for both the traditional
CMS and the PSKmixing variation specified in this document would be
a violation of this principle; however, there is no known way for an
attacker to take advantage of this situation. That said, an
application should enforce separation whenever possible. For example, a purpose identifier for use in the X.509 extended key usage
certificate extension could be identified in the future to
indicate that a public key should only be used in conjunction with or
without a PSK.
Implementations must randomly generate keyderivation keys as well as
contentencryption keys or contentauthenticatedencryption keys.
Also, the generation of public/private key pairs for the key
transport and key agreement algorithms rely on random numbers. The
use of inadequate pseudorandom number generators (PRNGs) to generate
cryptographic keys can result in little or no security. An attacker
may find it much easier to reproduce the PRNG environment that
produced the keys, searching the resulting small set of
possibilities, rather than bruteforce searching the whole key space.
The generation of quality random numbers is difficult.
offers important guidance in this area.
Implementers should be aware that cryptographic algorithms become
weaker with time. As new cryptanalysis techniques are developed and
computing performance improves, the work factor to break a particular
cryptographic algorithm will be reduced. Therefore, cryptographic
algorithm implementations should be modular, allowing new algorithms
to be readily inserted. That is, implementers should be prepared for
the set of supported algorithms to change over time.
The security properties provided by the mechanisms specified in this
document can be validated using formal methods. A ProVerif proof in
shows that an attacker with a largescale quantum computer
that is capable of breaking the DiffieHellman key agreement
algorithm cannot disrupt the delivery of the contentencryption key
to the recipient and that the attacker cannot learn the contentencryption
key from the protocol exchange.
Privacy Considerations
An observer can see which parties are using each PSK simply by
watching the PSK key identifiers. However, the addition of these key identifiers does not really weaken
the privacy situation. When key transport
is used, the RecipientIdentifier is always present, and it clearly
identifies each recipient to an observer. When key agreement is
used, either the IssuerAndSerialNumber or the RecipientKeyIdentifier
is always present, and these clearly identify each recipient.
IANA Considerations
One object identifier for the ASN.1 module in was assigned
in the "SMI Security for S/MIME Module Identifier
(1.2.840.113549.1.9.16.0)" registry :
One new entry has been added in the "SMI Security for S/MIME Mail
Security (1.2.840.113549.1.9.16)" registry :
A new registry titled "SMI Security for S/MIME Other
Recipient Info Identifiers (1.2.840.113549.1.9.16.13)" has been created.
Updates to the new registry are to be made according to the
Specification Required policy as defined in . The expert is expected to ensure that any new values identify additional
RecipientInfo structures for use with the CMS. Object identifiers
for other purposes should not be assigned in this arc.
Two assignments were made in the new "SMI Security for S/MIME Other Recipient
Info Identifiers (1.2.840.113549.1.9.16.13)" registry
with references to this document:
References
Normative References
Information technology  Abstract Syntax Notation One (ASN.1): Specification of basic notation
ITUT
Information technology  ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
ITUT
Informative References
Advanced Encryption Standard (AES)
National Institute of Standards and Technology
A kilobit hidden SNFS discrete logarithm computation
Subject: [lamps] WG Last Call for
draftietflampscmsmixwithpsk"
message to the IETF mailing list
Structure of Management Information (SMI) Numbers (MIB Module Registrations)
IANA
Quantum Computing: Progress and Prospects
National Academies of Sciences, Engineering, and Medicine
Recommendation for KeyDerivation Methods in KeyEstablishment Schemes
Algorithms for Quantum Computation: Discrete Logarithms and Factoring
Proceedings of the 35th Annual Symposium on Foundations of Computer Science, pp. 124134"
Key Transport with PSK Example
This example shows the establishment of an AES256 contentencryption
key using:
 a preshared key of 256 bits;
 key transport using RSA PKCS#1 v1.5 with a 3072bit key;
 key derivation using HKDF with SHA384; and
 key wrap using AES256KEYWRAP.
In realworld use, the originator would encrypt the keyderivation
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.
Originator Processing Example
The preshared key known to Alice and Bob, in hexadecimal, is:
The identifier assigned to the preshared key is:
Alice obtains Bob's public key:
Bob's RSA public key has the following key identifier:
Alice randomly generates a contentencryption key:
Alice randomly generates a keyderivation key:
Alice encrypts the keyderivation key in Bob's public key:
Alice produces a 256bit keyencryption key with HKDF using
SHA384; the secret value is the keyderivation key; and the 'info' is the DERencoded CMSORIforPSKOtherInfo structure with the following values:
The DER encoding of CMSORIforPSKOtherInfo produces 58 octets:
The HKDF output is 256 bits:
Alice uses AESKEYWRAP to encrypt the 256bit contentencryption key with the keyencryption key:
Alice encrypts the content using AES256GCM with the contentencryption key. The 12octet nonce used is:
The content plaintext is:
The resulting ciphertext is:
The resulting 12octet authentication tag is:
ContentInfo and AuthEnvelopedData
Alice encodes the AuthEnvelopedData and the ContentInfo and
sends the result to Bob. The resulting structure is:
Recipient Processing Example
Bob's private key is:
Bob decrypts the keyderivation key with his RSA private key:
Bob produces a 256bit keyencryption key with HKDF using SHA384;
the secret value is the keyderivation key; and the 'info' is
the DERencoded CMSORIforPSKOtherInfo structure with the same
values as shown in . The HKDF output is 256 bits:
Bob uses AESKEYWRAP to decrypt the contentencryption key with the keyencryption key; the contentencryption key is:
Bob decrypts the content using AES256GCM with the contentencryption key and checks the received authentication tag. The 12octet nonce used is:
The 12octet authentication tag is:
The received ciphertext content is:
The resulting plaintext content is:
Key Agreement with PSK Example
This example shows the establishment of an AES256 contentencryption
key using:
 a preshared key of 256 bits;
 key agreement using ECDH on curve P384 and X9.63 KDF
with SHA384;
 key derivation using HKDF with SHA384; and
 key wrap using AES256KEYWRAP.
In realworld use, the originator would treat themselves as an
additional recipient by performing key agreement with their own
static public key and the ephemeral private key generated for this
message. This is omitted in an attempt to simplify the example.
Originator Processing Example
The preshared key known to Alice and Bob, in hexadecimal, is:
The identifier assigned to the preshared key is:
Alice randomly generates a contentencryption key:
Alice obtains Bob's static ECDH public key:
It has a key identifier of:
Alice generates an ephemeral ECDH key pair on the same curve:
Alice computes a shared secret called "Z" using Bob's static ECDH
public key and her ephemeral ECDH private key; Z is:
Alice computes the pairwise keyencryption key, called "KEK1", from Z using
the X9.63 KDF with the ECCCMSSharedInfo structure with the following values:
The DER encoding of ECCCMSSharedInfo produces 23 octets:
The X9.63 KDF output is the 256bit KEK1:
Alice produces the 256bit KEK2 with HKDF using SHA384; the secret
value is KEK1; and the 'info' is the DERencoded CMSORIforPSKOtherInfo
structure with the following values:
The DER encoding of CMSORIforPSKOtherInfo produces 58 octets:
The HKDF output is the 256bit KEK2:
Alice uses AESKEYWRAP to encrypt the contentencryption key with the KEK2; the wrapped key is:
Alice encrypts the content using AES256GCM with the contentencryption key. The 12octet nonce used is:
The plaintext is:
The resulting ciphertext is:
The resulting 12octet authentication tag is:
ContentInfo and AuthEnvelopedData
Alice encodes the AuthEnvelopedData and the ContentInfo and
sends the result to Bob. The resulting structure is:
Recipient Processing Example
Bob obtains Alice's ephemeral ECDH public key from the message:
Bob's static ECDH private key is:
Bob computes a shared secret called "Z" using Alice's ephemeral
ECDH public key and his static ECDH private key; Z is:
Bob computes the pairwise keyencryption key, KEK1, from Z using
the X9.63 KDF with the ECCCMSSharedInfo structure with the values shown
in . The X9.63 KDF output is the 256bit KEK1:
Bob produces the 256bit KEK2 with HKDF using SHA384; the secret value
is KEK1; and the 'info' is the DERencoded CMSORIforPSKOtherInfo structure with
the values shown in . The HKDF output is the 256bit KEK2:
Bob uses AESKEYWRAP to decrypt the contentencryption key with the
KEK2; the contentencryption key is:
Bob decrypts the content using AES256GCM with the contentencryption
key and checks the received authentication tag. The 12octet nonce used is:
The 12octet authentication tag is:
The received ciphertext content is:
The resulting plaintext content is:
Acknowledgements
Many thanks to Roman Danyliw, Ben Kaduk, Burt Kaliski, Panos
Kampanakis, Jim Schaad, Robert Sparks, Sean Turner, and Daniel Van
Geest for their review and insightful comments. They have greatly
improved the design, clarity, and implementation guidance.