draft-ietf-lamps-cms-mix-with-psk-06.txt   draft-ietf-lamps-cms-mix-with-psk-07.txt 
INTERNET-DRAFT R. Housley INTERNET-DRAFT R. Housley
Internet Engineering Task Force (IETF) Vigil Security Internet Engineering Task Force (IETF) Vigil Security
Intended Status: Proposed Standard Intended Status: Proposed Standard
Expires: 6 February 2020 6 August 2019 Expires: 23 February 2020 23 August 2019
Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)
<draft-ietf-lamps-cms-mix-with-psk-06.txt> <draft-ietf-lamps-cms-mix-with-psk-07.txt>
Abstract Abstract
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
skipping to change at page 5, line 7 skipping to change at page 5, line 7
then all recipients obtain that key. All recipients use the sender- then all recipients obtain that key. All recipients use the sender-
generated symmetric content-encryption key for decryption. generated symmetric content-encryption key for decryption.
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 content-encryption key. In both cases, the PSK is used as generated content-encryption key. In both cases, the PSK is used as
one of the inputs to a key-derivation function to create a quantum- one of the inputs to a key-derivation function to create a quantum-
resistant key-encryption key. The PSK MUST be distributed to the resistant key-encryption key. The PSK MUST 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. 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 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: quantum-resistant, and the sender establishes it using these steps:
When using a key transport algorithm: When using a key transport algorithm:
1. The content-encryption key or the content-authenticated- 1. The content-encryption key or the content-authenticated-
encryption key, called CEK, is generated at random. encryption key, called CEK, is generated at random.
2. The key-derivation key, called KDK, is generated at random. 2. The key-derivation key, called KDK, is generated at random.
skipping to change at page 7, line 21 skipping to change at page 7, line 27
The KeyDerivationAlgorithmIdentifier is described in Section The KeyDerivationAlgorithmIdentifier is described in Section
10.1.6 of [RFC5652]. 10.1.6 of [RFC5652].
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 Section 10.1.3 of
[RFC5652]. [RFC5652].
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
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 Section 6.2.1 of
[RFC5652]. [RFC5652].
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 key. EncryptedKey is an OCTET STRING. encryption key. EncryptedKey is an OCTET STRING.
4. keyAgreePSK 4. keyAgreePSK
Per-recipient information using keyAgreePSK is represented in the Per-recipient information using keyAgreePSK is represented in the
skipping to change at page 9, line 14 skipping to change at page 9, line 27
encrypting the content-encryption key or the content- encrypting the content-encryption key or the content-
authenticated-encryption key with the second pairwise key- authenticated-encryption key with the second pairwise key-
encryption key. EncryptedKey is an OCTET STRING. The encryption key. EncryptedKey is an OCTET STRING. The
RecipientEncryptedKeys type is defined in Section 6.2.2 of RecipientEncryptedKeys type is defined in Section 6.2.2 of
[RFC5652]. [RFC5652].
5. Key Derivation 5. Key Derivation
Many key derivation functions (KDFs) internally employ a one-way hash 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
identified by the KeyDerivationAlgorithmIdentifier. HKDF [RFC5869] indirectly indicated by the KeyDerivationAlgorithmIdentifier. HKDF
is one example of a KDF that makes use of a hash function. [RFC5869] 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, AES-128-CMAC can be
used for randomness extraction in a KDF as described in [NIST2018].
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 [RFC5869] specification simplicity, the terminology used in the HKDF [RFC5869] specification
is used here. is used here.
The KDF inputs are: The KDF inputs are:
IKM is the input keying material; it is the symmetric secret input IKM is the input keying material; it is the symmetric secret input
to the KDF. For KeyTransPSKRecipientInfo, it is the key- to the KDF. For KeyTransPSKRecipientInfo, it is the key-
derivation key. For KeyAgreePSKRecipientInfo, it is the pairwise derivation key. For KeyAgreePSKRecipientInfo, it is the pairwise
key-encryption key produced by the key agreement algorithm. key-encryption key produced by the key agreement algorithm.
salt is an optional non-secret random value. The salt is not salt is an optional non-secret random value. Many KDFs do not
used. require a salt, and the KeyDerivationAlgorithmIdentifier
assignments for HKDF [RFC8619] 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 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. value, called info.
info is optional context and application specific information. 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
skipping to change at page 10, line 42 skipping to change at page 11, line 11
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. key-encryption key produced by the key agreement algorithm.
The KDF output is: The KDF output is:
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-
encryption key or the content-authenticated-encryption key. encryption key or the content-authenticated-encryption key.
An acceptable KDF MUST accept IKM, L, and info inputs; and 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.
6. ASN.1 Module 6. ASN.1 Module
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 [RFC5911] and [RFC5912]. other ASN.1 modules that are defined in [RFC5912] and [RFC6268].
<CODE BEGINS> <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(TBD0) }
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
skipping to change at page 13, line 7 skipping to change at page 13, line 33
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
pskLength INTEGER (1..MAX), pskLength INTEGER (1..MAX),
kdkLength INTEGER (1..MAX) } kdkLength INTEGER (1..MAX) }
END END
<CODE ENDS> <CODE ENDS>
7. Security Considerations 7. Security Considerations
The security considerations in related to the CMS enveloped-data
content type in [RFC5652] and the security considerations related to
the CMS authenticated-enveloped-data content type in [RFC5083]
continue to apply.
Implementations of the key derivation function must compute the
entire result, which in this specification is a key-encryption key,
before outputting any portion of the result. The resulting key-
encryption key must be protected. Compromise of the key-encryption
key may result in the disclosure of all content-encryption keys or
content-authenticated-encryption keys that were protected with that
keying material, which in turn may result in the disclosure of the
content. Note that there are two key-encryption keys when a PSK with
a key agreement algorithm is used, with similar consequence for the
compromise of either one of these keys.
Implementations must protect the pre-shared key (PSK), key transport Implementations must protect the pre-shared key (PSK), key transport
private key, the agreement private key, the key-derivation key, and private key, the agreement private key, and the key-derivation key.
the key-encryption key. Compromise of the PSK will make the Compromise of the PSK will make the encrypted content vulnerable to
encrypted content vulnerable to the future invention of a large-scale the future invention of a large-scale quantum computer. Compromise
quantum computer. Compromise of the PSK and either the key transport of the PSK and either the key transport private key or the agreement
private key or the agreement private key may result in the disclosure private key may result in the disclosure of all contents protected
of all contents protected with that combination of keying material. with that combination of keying material. Compromise of the PSK and
Compromise of the PSK and the key-derivation key may result in the key-derivation key may result in disclosure of all contents
disclosure of all contents protected with that combination of keying protected with that combination of keying material.
material. Compromise of the key-encryption key may result in the
disclosure of all content-encryption keys or content-authenticated-
encryption keys that were protected with that keying material, which
in turn may result in the disclosure of the content.
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 quantum computer effectively cuts the security provided by a scale quantum 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
skipping to change at page 13, line 46 skipping to change at page 14, line 36
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 of protection is provided. Implementers must ensure that 128 bits of protection is 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. algorithm.
The selection of the key-derivation function imposes an upper bound
on the strength of the resulting key-encryption key. The strength of
the selected key-derivation function should be at least as strong as
the key-encryption algorithm that is selected. NIST SP 800-56C
Revision 1 [NIST2018] offers advice on the security strength of
several popular key-derivation functions.
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. to the future invention of a large-scale quantum computer.
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. vulnerable to the future invention of a large-scale quantum computer.
This specification does not require that PSK is 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 enable
eavesdropping. However, group members can record the traffic of inherently eavesdropping. However, group members can record the
other members, and then decrypt it if they ever gain access to a traffic of other members, and then decrypt it if they ever gain
large-scale quantum computer. Also, when many parties know the PSK, access to a large-scale quantum computer. Also, when many parties
there are many opportunities for theft of the PSK by an attacker. know the PSK, there are many opportunities for theft of the PSK by an
Once an attacker has the PSK, they can decrypt stored traffic if they attacker. Once an attacker has the PSK, they can decrypt stored
ever gain access to a large-scale quantum computer in the same manner traffic if they ever gain access to a large-scale quantum computer in
as a legitimate group member. the same manner as a legitimate group member.
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 purpose identifier for use in the X.509 extended key usage example, a purpose identifier for use in the X.509 extended key usage
certificate extension [RFC5280] could be identified in the future to certificate extension [RFC5280] could be identified 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 a
skipping to change at page 14, line 48 skipping to change at page 15, line 46
transport and key agreement algorithms rely on a random numbers. The transport and key agreement algorithms rely on a random numbers. The
use of inadequate pseudo-random number generators (PRNGs) to generate use of inadequate pseudo-random 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. [RFC4086] The generation of quality random numbers is difficult. [RFC4086]
offers important guidance in this area. offers important guidance in this area.
Implementers should be aware that cryptographic algorithms become Implementers should be aware that cryptographic algorithms become
weaker with time. As new cryptoanalysis 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. the set of supported algorithms to change over time.
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
[H2019] shows that an attacker with a large-scale quantum computer [H2019] shows that an attacker with a large-scale quantum computer
that is capable of breaking the Diffie-Hellman key agreement that is capable of breaking the Diffie-Hellman key agreement
skipping to change at page 15, line 41 skipping to change at page 16, line 40
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) TBD0 }
One new registry was created for Other Recipient Info Identifiers One new registry was created for Other Recipient Info Identifiers
within the SMI Security for S/MIME Mail Security within the SMI Security for S/MIME Mail Security
(1.2.840.113549.1.9.16) [IANA-SMIME] registry: (1.2.840.113549.1.9.16) [IANA-SMIME] registry:
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) TBD1 }
Updates to the new registry are to be made according to the
Specification Required policy as defined in [RFC8126]. The expert is
expected to ensure that any new values identify additions
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 Other Recipient Two assignments were made in the new SMI Security for Other Recipient
Info Identifiers (1.2.840.113549.1.9.16.TBD1) [IANA-ORI] registry Info Identifiers (1.2.840.113549.1.9.16.TBD1) [IANA-ORI] registry
with references to this document: with references to this document:
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(TBD1) 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)
skipping to change at page 16, line 19 skipping to change at page 17, line 31
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type", RFC 5083, Authenticated-Enveloped-Data Content Type", RFC 5083,
November 2007. November 2007.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
5652, September 2009. 5652, September 2009.
[RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
June 2010.
[RFC6268] Schaad, J., S. Turner, "Additional New ASN.1 Modules for
the Cryptographic Message Syntax (CMS) and the Public Key
Infrastructure Using X.509 (PKIX)", RFC 6268, July 2011.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, June 2017.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017. 2119 Key Words", BCP 14, RFC 8174, May 2017.
[X680] ITU-T, "Information technology -- Abstract Syntax Notation [X680] ITU-T, "Information technology -- Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, 2015. Recommendation X.680, 2015.
[X690] ITU-T, "Information technology -- ASN.1 encoding rules: [X690] ITU-T, "Information technology -- ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, 2015. (DER)", ITU-T Recommendation X.690, 2015.
10.2. Informative References 10.2. Informative References
[AES] National Institute of Standards and Technology, FIPS Pub [AES] National Institute of Standards and Technology, FIPS Pub
197: Advanced Encryption Standard (AES), 26 November 2001. 197: Advanced Encryption Standard (AES), 26 November 2001.
[C2PQ] Hoffman, P., "The Transition from Classical to Post- [C2PQ] Hoffman, P., "The Transition from Classical to Post-
Quantum Cryptography", work-in-progress, draft-hoffman- Quantum Cryptography", work-in-progress, draft-hoffman-
c2pq-04, August 2018. c2pq-05, August 2018.
[FGHT2016] Fried, J., Gaudry, P., Heninger, N., and E. Thome, "A [FGHT2016] Fried, J., Gaudry, P., Heninger, N., and E. Thome, "A
kilobit hidden SNFS discrete logarithm computation", kilobit hidden SNFS discrete logarithm computation",
Cryptology ePrint Archive, Report 2016/961, 2016. Cryptology ePrint Archive, Report 2016/961, 2016.
https://eprint.iacr.org/2016/961.pdf. https://eprint.iacr.org/2016/961.pdf.
[H2019] Hammell, J., "Re: [lamps] WG Last Call for draft-ietf- [H2019] Hammell, J., "Re: [lamps] WG Last Call for draft-ietf-
lamps-cms-mix-with-psk", <https://mailarchive.ietf.org/ lamps-cms-mix-with-psk", <https://mailarchive.ietf.org/
arch/msg/spasm/_6d_4jp3sOprAnbU2fp_yp_-6-k>, 27 May 2019. arch/msg/spasm/_6d_4jp3sOprAnbU2fp_yp_-6-k>, 27 May 2019.
skipping to change at page 17, line 13 skipping to change at page 18, line 41
[IANA-SMIME] https://www.iana.org/assignments/smi-numbers/smi- [IANA-SMIME] https://www.iana.org/assignments/smi-numbers/smi-
numbers.xhtml#security-smime. numbers.xhtml#security-smime.
[IANA-ORI] https://www.iana.org/assignments/smi-numbers/smi- [IANA-ORI] https://www.iana.org/assignments/smi-numbers/smi-
numbers.xhtml#security-smime-TBD1. numbers.xhtml#security-smime-TBD1.
[NAS2019] National Academies of Sciences, Engineering, and Medicine, [NAS2019] National Academies of Sciences, Engineering, and Medicine,
"Quantum Computing: Progress and Prospects", The National "Quantum Computing: Progress and Prospects", The National
Academies Press, DOI 10.17226/25196, 2019. Academies Press, DOI 10.17226/25196, 2019.
[NIST2018] Barker, E., Chen, L., and R. Davis, "Recommendation for
Key-Derivation Methods in Key-Establishment Schemes",
NIST Special Publication 800-56C Rev. 1, April 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Cr1.pdf>.
[S1994] Shor, P., "Algorithms for Quantum Computation: Discrete [S1994] Shor, P., "Algorithms for Quantum Computation: Discrete
Logarithms and Factoring", Proceedings of the 35th Annual Logarithms and Factoring", Proceedings of the 35th Annual
Symposium on Foundations of Computer Science, 1994, pp. Symposium on Foundations of Computer Science, 1994, pp.
124-134. 124-134.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999. RFC 2631, June 1999.
[RFC4086] D. Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] D. Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", RFC 4086, "Randomness Requirements for Security", RFC 4086,
skipping to change at page 17, line 38 skipping to change at page 19, line 25
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5753] Turner, S., and D. Brown, "Use of Elliptic Curve [RFC5753] Turner, S., and D. Brown, "Use of Elliptic Curve
Cryptography (ECC) Algorithms in Cryptographic Message Cryptography (ECC) Algorithms in Cryptographic Message
Syntax (CMS)", RFC 5753, January 2010. Syntax (CMS)", RFC 5753, January 2010.
[RFC5869] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- [RFC5869] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and-
Expand Key Derivation Function (HKDF)", RFC 5869, Expand Key Derivation Function (HKDF)", RFC 5869,
May 2010. May 2010.
[RFC5911] Hoffman, P., and J. Schaad, "New ASN.1 Modules for
Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
June 2010.
[RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
June 2010.
[RFC6268] Schaad, J., S. Turner, "Additional New ASN.1 Modules for
the Cryptographic Message Syntax (CMS) and the Public Key
Infrastructure Using X.509 (PKIX)", RFC 6268, July 2011.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, November 2016. RFC 8017, November 2016.
[RFC8619] Housley, R., "Algorithm Identifiers for the HMAC-based
Extract-and-Expand Key Derivation Function (HKDF)", June
2019.
Appendix A: Key Transport with PSK Example Appendix A: Key Transport with PSK Example
This example shows the establishment of an AES-256 content-encryption This example shows the establishment of an AES-256 content-encryption
key using: key using:
- a pre-shared key of 256 bits; - a pre-shared key of 256 bits;
- key transport using RSA PKCS#1 v1.5 with a 3072-bit key; - key transport using RSA PKCS#1 v1.5 with a 3072-bit key;
- key derivation using HKDF with SHA-384; and - key derivation using HKDF with SHA-384; and
- key wrap using AES-256-KEYWRAP. - key wrap using AES-256-KEYWRAP.
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. key. This is omitted in an attempt to simplify the example.
A.1. Originator Processing Example A.1. Originator Processing Example
The pre-shared key known to Alice and Bob: The pre-shared key known to Alice and Bob, in hexadecimal:
c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb05213365cf95b15 c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb05213365cf95b15
The identifier assigned to the pre-shared key is: The identifier assigned to the pre-shared key is:
ptf-kmc:13614122112 ptf-kmc:13614122112
Alice obtains Bob's public key: Alice obtains Bob's public key:
-----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
skipping to change at page 24, line 46 skipping to change at page 25, line 46
- key derivation using HKDF with SHA-384; and - key derivation using HKDF with SHA-384; and
- key wrap using AES-256-KEYWRAP. - key wrap using AES-256-KEYWRAP.
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. message. This is omitted in an attempt to simplify the example.
B.1. Originator Processing Example B.1. Originator Processing Example
The pre-shared key known to Alice and Bob: The pre-shared key known to Alice and Bob, in hexadecimal:
4aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c078660214e2d83e4 4aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c078660214e2d83e4
The identifier assigned to the pre-shared key is: The identifier assigned to the pre-shared key is:
ptf-kmc:216840110121 ptf-kmc:216840110121
Alice randomly generates a content-encryption key: Alice randomly generates a content-encryption key:
937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033 937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033
Alice obtains Bob's static ECDH public key: Alice obtains Bob's static ECDH public key:
-----BEGIN PUBLIC KEY----- -----BEGIN PUBLIC KEY-----
skipping to change at page 30, line 7 skipping to change at page 30, line 41
550260c42e5b29719426c1ff 550260c42e5b29719426c1ff
The received ciphertext content is: The received ciphertext content is:
fc6d6f823e3ed2d209d0c6ffcf fc6d6f823e3ed2d209d0c6ffcf
The resulting plaintext content is: The resulting plaintext content is:
48656c6c6f2c20776f726c6421 48656c6c6f2c20776f726c6421
Acknowledgements Acknowledgements
Many thanks to Roman Danyliw, Burt Kaliski, Panos Kampanakis, Jim Many thanks to Roman Danyliw, Ben Kaduk, Burt Kaliski, Panos
Schaad, Robert Sparks, Sean Turner, and Daniel Van Geest for their Kampanakis, Jim Schaad, Robert Sparks, Sean Turner, and Daniel Van
review and insightful comments. They have greatly improved the Geest for their review and insightful comments. They have greatly
design, clarity, and implementation guidance. improved the design, clarity, and implementation guidance.
Author's Address Author's Address
Russ Housley Russ Housley
Vigil Security, LLC Vigil Security, LLC
516 Dranesville Road 516 Dranesville Road
Herndon, VA 20170 Herndon, VA 20170
USA USA
EMail: housley@vigilsec.com EMail: housley@vigilsec.com
 End of changes. 22 change blocks. 
47 lines changed or deleted 104 lines changed or added

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