draft-ietf-lamps-cms-mix-with-psk-05.txt   draft-ietf-lamps-cms-mix-with-psk-06.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: 5 December 2019 5 June 2019 Expires: 6 February 2020 6 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-05.txt> <draft-ietf-lamps-cms-mix-with-psk-06.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 2, line 47 skipping to change at page 2, line 47
B.1. Originator Processing Example . . . . . . . . . . . . . . 23 B.1. Originator Processing Example . . . . . . . . . . . . . . 23
B.2. ContentInfo and AuthEnvelopedData . . . . . . . . . . . . 26 B.2. ContentInfo and AuthEnvelopedData . . . . . . . . . . . . 26
B.3. Recipient Processing Example . . . . . . . . . . . . . . . 27 B.3. Recipient Processing Example . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 29 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
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. It is an open question whether or not it is feasible to build today [S1994]. It is an open question whether or not it is feasible
a large-scale quantum computer, and if so, when that might happen. to build a large-scale quantum computer, and if so, when that might
However, if such a quantum computer is invented, many of the happen [NAS2019]. However, if such a quantum computer is invented,
cryptographic algorithms and the security protocols that use them many of the cryptographic algorithms and the security protocols that
would become vulnerable. use them would become vulnerable.
The Cryptographic Message Syntax (CMS) [RFC5652][RFC5083] supports The Cryptographic Message Syntax (CMS) [RFC5652][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 [C2PQ]. These the invention of a large-scale quantum computer [C2PQ]. These
algorithms include RSA [RFC8017], Diffie-Hellman [RFC2631], and algorithms include RSA [RFC8017], Diffie-Hellman [RFC2631], and
Elliptic Curve Diffie-Hellman [RFC5753]. As a result, an adversary Elliptic Curve Diffie-Hellman [RFC5753]. As a result, an adversary
that stores CMS-protected communications today, could decrypt those 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. becomes available.
skipping to change at page 3, line 30 skipping to change at page 3, line 30
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 [RFC8017], or output of an existing key transport algorithm, like RSA [RFC8017], or
an existing key agreement algorithm, like Diffie-Hellman [RFC2631] or an existing key agreement algorithm, like Diffie-Hellman [RFC2631] or
Elliptic Curve Diffie-Hellman [RFC5753]. A security solution that is Elliptic Curve Diffie-Hellman [RFC5753]. 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 [RFC5869], and a quantum resistant function (KDF), like HKDF [RFC5869], and a quantum resistant
encryption algorithm, like 256-bit AES [AES]. In this way, today's encryption algorithm, like 256-bit AES [AES]. In this way, today's
CMS-protected communication can be invulnerable to an attacker with a CMS-protected communication can be resistant to an attacker with a
large-scale quantum computer. large-scale quantum computer.
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 of the classic public-key
algorithm, and there are longstanding concerns about undisclosed algorithm, and there are longstanding concerns about undisclosed
trapdoors in Diffie-Hellamn parameters. Inclusion of a strong PSK as trapdoors in Diffie-Hellman parameters [FGHT2016]. Inclusion of a
part of the overall key management offer additional protection strong PSK as part of the overall key management offer additional
against these concerns. protection against these concerns.
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. derivation function and a sufficiently large password.
1.1. Terminology 1.1. Terminology
skipping to change at page 6, line 15 skipping to change at page 6, line 15
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. the content-encryption key or content-authenticated-encryption key.
The second key management technique, called keyAgreePSK, see The second key management technique, called keyAgreePSK, see
Section 4, uses a key agreement algorithm to establish a pairwise Section 4, uses a key agreement algorithm to establish a pairwise
key-encryption key, which is then mixed with the PSK using a KDF to key-encryption key, which is then mixed with the PSK using a 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- encrypt the content-encryption key or content-authenticated-
encryption key. encryption key.
3. KeyTransPSKRecipientInfo 3. keyTransPSK
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 object identifier. Each instance of keyTransPSK object 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. have access to the same PSK.
The id-ori-keyTransPSK object identifier is: The id-ori-keyTransPSK object identifier is:
skipping to change at page 7, line 28 skipping to change at page 7, line 28
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. 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. KeyAgreePSKRecipientInfo 4. keyAgreePSK
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 object identifier. Each instance of keyAgreePSK object 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. have access to the same PSK.
The id-ori-keyAgreePSK object identifier is: The id-ori-keyAgreePSK object identifier is:
skipping to change at page 9, line 15 skipping to change at page 9, line 15
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] identified by the KeyDerivationAlgorithmIdentifier. HKDF [RFC5869]
is one example of a KDF that make use fo a hash function. is one example of a KDF that makes use of a hash function.
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
skipping to change at page 9, line 43 skipping to change at page 9, line 43
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
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 deines 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: ASN.1 structure:
CMSORIforPSKOtherInfo ::= SEQUENCE { CMSORIforPSKOtherInfo ::= SEQUENCE {
psk OCTET STRING, psk OCTET STRING,
keyMgmtAlgType ENUMERATED { keyMgmtAlgType ENUMERATED {
keyTrans (5), keyTrans (5),
keyAgree (10) }, keyAgree (10) },
skipping to change at page 11, line 28 skipping to change at page 11, line 28
AlgorithmIdentifier{}, KEY-DERIVATION AlgorithmIdentifier{}, KEY-DERIVATION
FROM AlgorithmInformation-2009 -- [RFC5912] FROM AlgorithmInformation-2009 -- [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) } id-mod-algorithmInformation-02(58) }
OTHER-RECIPIENT, OtherRecipientInfo, CMSVersion, OTHER-RECIPIENT, OtherRecipientInfo, CMSVersion,
KeyTransRecipientInfo, OriginatorIdentifierOrKey, KeyTransRecipientInfo, OriginatorIdentifierOrKey,
UserKeyingMaterial, RecipientEncryptedKeys, EncryptedKey, UserKeyingMaterial, RecipientEncryptedKeys, EncryptedKey,
KeyDerivationAlgorithmIdentifier, KeyEncryptionAlgorithmIdentifier KeyDerivationAlgorithmIdentifier, KeyEncryptionAlgorithmIdentifier
FROM CryptographicMessageSyntax-2009 -- [RFC5911] FROM CryptographicMessageSyntax-2010 -- [RFC6268]
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-2004-02(41) } ; id-mod-cms-2009(58) } ;
-- --
-- OtherRecipientInfo Types (ori-) -- OtherRecipientInfo Types (ori-)
-- --
SupportedOtherRecipInfo OTHER-RECIPIENT ::= { SupportedOtherRecipInfo OTHER-RECIPIENT ::= {
ori-keyTransPSK | ori-keyTransPSK |
ori-keyAgreePSK, ori-keyAgreePSK,
... } ... }
skipping to change at page 12, line 20 skipping to change at page 12, line 20
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
PreSharedKeyIdentifier ::= OCTET STRING PreSharedKeyIdentifier ::= OCTET STRING
KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo
-- --
-- Key Agreement with Pre-Shared Key -- Key Agreement with Pre-Shared Key
-- --
ori-keyAgreePSK ORI-TYPE ::= { ori-keyAgreePSK OTHER-RECIPIENT ::= {
KeyAgreePSKRecipientInfo IDENTIFIED BY id-ori-keyAgreePSK } KeyAgreePSKRecipientInfo IDENTIFIED BY id-ori-keyAgreePSK }
id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 }
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,
skipping to change at page 13, line 18 skipping to change at page 13, line 18
private key, the agreement private key, the key-derivation key, and private key, the agreement private key, the key-derivation key, and
the key-encryption key. Compromise of the PSK will make the the key-encryption key. Compromise of the PSK will make the
encrypted content vulnerable to the future invention of a large-scale encrypted content vulnerable to the future invention of a large-scale
quantum computer. Compromise of the PSK and either the key transport quantum computer. Compromise of the PSK and either the key transport
private key or the agreement private key may result in the disclosure private key or the agreement private key may result in the disclosure
of all contents protected with that combination of keying material. of all contents protected with that combination of keying material.
Compromise of the PSK and the key-derivation key may result in Compromise of the PSK and the key-derivation key may result in
disclosure of all contents protected with that combination of keying disclosure of all contents protected with that combination of keying
material. Compromise of the key-encryption key may result in the material. Compromise of the key-encryption key may result in the
disclosure of all content-encryption keys or content-authenticated- disclosure of all content-encryption keys or content-authenticated-
encryption keys that were protected with that keying materail, which encryption keys that were protected with that keying material, which
in turn may result in the disclosure of the content. 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
skipping to change at page 14, line 30 skipping to change at page 14, line 30
Once an attacker has the PSK, they can decrypt stored traffic if they Once an attacker has the PSK, they can decrypt stored traffic if they
ever gain access to a large-scale quantum computer in the same manner ever gain access to a large-scale quantum computer in the same manner
as a legitimate group member. 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, an purpose identifier for use in the X.509 extended key example, a purpose identifier for use in the X.509 extended key usage
usage certificate extension [RFC5280] could be identified in the certificate extension [RFC5280] could be identified in the future to
future to indicate that a public key should only be used in indicate that a public key should only be used in conjunction with a
conjunction with a PSK, or only without. PSK, or only without.
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. the 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 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 cryptoanalysis 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, implementors 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
document can be validated using formal methods. A ProVerif proof in
[H2019] shows that an attacker with a large-scale quantum computer
that is capable of breaking the Diffie-Hellman key agreement
algorithm cannot disrupt the delivery of the content-encryption key
to the recipient and the attacker cannot learn the content-encryption
key from the protocol exchange.
8. Privacy Considerations 8. Privacy Considerations
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
identifiers is not really making privacy worse. When key transport identifiers is not really making privacy worse. 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. is always present, and these clearly identify each recipient.
9. IANA Considerations 9. IANA Considerations
One object identifier for the ASN.1 module in the Section 5 was One object identifier for the ASN.1 module in Section 6 was assigned
assigned in the SMI Security for S/MIME Module Identifiers in the SMI Security for S/MIME Module Identifiers
(1.2.840.113549.1.9.16.0) [IANA-MOD] registry: (1.2.840.113549.1.9.16.0) [IANA-MOD] registry:
id-mod-cms-ori-psk-2017 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) TBD0 }
One object identifier for an arc to assign Other Recipient Info One new registry was created for Other Recipient Info Identifiers
Identifiers was assigned in 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 }
This assignment created the new SMI Security for Other Recipient Info Two assignments were made in the new SMI Security for Other Recipient
Identifiers (1.2.840.113549.1.9.16.TBD1) [IANA-ORI] registry with the Info Identifiers (1.2.840.113549.1.9.16.TBD1) [IANA-ORI] registry
following two entries 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)
pkcs-9(9) smime(16) id-ori(TBD1) 2 } pkcs-9(9) smime(16) id-ori(TBD1) 2 }
10. References 10. References
10.1. Normative References 10.1. Normative References
[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.
[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:
skipping to change at page 16, line 40 skipping to change at page 16, line 40
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-04, August 2018.
[FGHT2016] Fried, J., Gaudry, P., Heninger, N., and E. Thome, "A
kilobit hidden SNFS discrete logarithm computation",
Cryptology ePrint Archive, Report 2016/961, 2016.
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.
[IANA-MOD] https://www.iana.org/assignments/smi-numbers/smi- [IANA-MOD] https://www.iana.org/assignments/smi-numbers/smi-
numbers.xhtml#security-smime-0. numbers.xhtml#security-smime-0.
[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-13. numbers.xhtml#security-smime-TBD1.
[NAS2019] National Academies of Sciences, Engineering, and Medicine,
"Quantum Computing: Progress and Prospects", The National
Academies Press, DOI 10.17226/25196, 2019.
[S1994] Shor, P., "Algorithms for Quantum Computation: Discrete
Logarithms and Factoring", Proceedings of the 35th Annual
Symposium on Foundations of Computer Science, 1994, pp.
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,
June 2005. June 2005.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
skipping to change at page 17, line 30 skipping to change at page 17, line 43
[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 [RFC5911] Hoffman, P., and J. Schaad, "New ASN.1 Modules for
Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
June 2010. June 2010.
[RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the [RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)" RFC 5912, Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
June 2010. 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.
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 omited 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:
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:
skipping to change at page 19, line 40 skipping to change at page 20, line 40
ae4ea1d99e78fcdcea12d9f10d991ac71502939ee0c30ebdcc97dd1fc5ba3566 ae4ea1d99e78fcdcea12d9f10d991ac71502939ee0c30ebdcc97dd1fc5ba3566
c83d0dd5d1b4faa5 c83d0dd5d1b4faa5
Alice encrypts the content using AES-256-GCM with the content- Alice encrypts the content using AES-256-GCM with the content-
encryption key. The 12-octet nonce used is: encryption key. The 12-octet nonce used is:
cafebabefacedbaddecaf888 cafebabefacedbaddecaf888
The content plaintext is: The content plaintext is:
48656c6c6f2c20776f726c6421 48656c6c6f2c20776f726c6421
The resutling ciphertext is: The resulting ciphertext is:
9af2d16f21547fcefed9b3ef2d 9af2d16f21547fcefed9b3ef2d
The resutling 12-octet authentication tag is: The resulting 12-octet authentication tag is:
a0e5925cc184e0172463c44c a0e5925cc184e0172463c44c
A.2. ContentInfo and AuthEnvelopedData A.2. ContentInfo and AuthEnvelopedData
Alice encodes the AuthEnvelopedData and the ContentInfo, and Alice encodes the AuthEnvelopedData and the ContentInfo, and
sends the result to Bob. The resulting structure is: sends the result to Bob. The resulting structure is:
0 650: SEQUENCE { 0 650: SEQUENCE {
4 11: OBJECT IDENTIFIER authEnvelopedData 4 11: OBJECT IDENTIFIER authEnvelopedData
: { 1 2 840 113549 1 9 16 1 23 } : { 1 2 840 113549 1 9 16 1 23 }
skipping to change at page 23, line 26 skipping to change at page 24, line 26
encryption key, and checks the received authentication tag. The encryption key, and checks the received authentication tag. The
12-octet nonce used is: 12-octet nonce used is:
cafebabefacedbaddecaf888 cafebabefacedbaddecaf888
The 12-octet authentication tag is: The 12-octet authentication tag is:
a0e5925cc184e0172463c44c a0e5925cc184e0172463c44c
The received ciphertext content is: The received ciphertext content is:
9af2d16f21547fcefed9b3ef2d 9af2d16f21547fcefed9b3ef2d
The resutling plaintext content is: The resulting plaintext content is:
48656c6c6f2c20776f726c6421 48656c6c6f2c20776f726c6421
Appendix B: Key Agreement with PSK Example Appendix B: Key Agreement 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 agreement using ECDH on curve P-384 and X9.63 KDF - key agreement using ECDH on curve P-384 and X9.63 KDF
with SHA-384; with SHA-384;
- 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 omited 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:
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:
skipping to change at page 25, line 37 skipping to change at page 26, line 37
Alice uses AES-KEY-WRAP to encrypt the content-encryption key Alice uses AES-KEY-WRAP to encrypt the content-encryption key
with the KEK2; the wrapped key is: with the KEK2; the wrapped key is:
229fe0b45e40003e7d8244ec1b7e7ffb2c8dca16c36f5737222553a71263a92b 229fe0b45e40003e7d8244ec1b7e7ffb2c8dca16c36f5737222553a71263a92b
de08866a602d63f4 de08866a602d63f4
Alice encrypts the content using AES-256-GCM with the content- Alice encrypts the content using AES-256-GCM with the content-
encryption key. The 12-octet nonce used is: encryption key. The 12-octet nonce used is:
dbaddecaf888cafebabeface dbaddecaf888cafebabeface
The plaintext is:
48656c6c6f2c20776f726c6421
The resulting ciphertext is: The resulting ciphertext is:
fc6d6f823e3ed2d209d0c6ffcf fc6d6f823e3ed2d209d0c6ffcf
The resulting 12-octet authentication tag is: The resulting 12-octet authentication tag is:
550260c42e5b29719426c1ff 550260c42e5b29719426c1ff
B.2. ContentInfo and AuthEnvelopedData B.2. ContentInfo and AuthEnvelopedData
Alice encodes the AuthEnvelopedData and the ContentInfo, and Alice encodes the AuthEnvelopedData and the ContentInfo, and
sends the result to Bob. The resulting structure is: sends the result to Bob. The resulting structure is:
skipping to change at page 28, line 36 skipping to change at page 29, line 36
encryption key, and checks the received authentication tag. The encryption key, and checks the received authentication tag. The
12-octet nonce used is: 12-octet nonce used is:
dbaddecaf888cafebabeface dbaddecaf888cafebabeface
The 12-octet authentication tag is: The 12-octet authentication tag is:
550260c42e5b29719426c1ff 550260c42e5b29719426c1ff
The received ciphertext content is: The received ciphertext content is:
fc6d6f823e3ed2d209d0c6ffcf fc6d6f823e3ed2d209d0c6ffcf
The resutling plaintext content is: The resulting plaintext content is:
48656c6c6f2c20776f726c6421 48656c6c6f2c20776f726c6421
Acknowledgements Acknowledgements
Many thanks to Burt Kaliski, Panos Kampanakis, Jim Schaad, Sean Many thanks to Roman Danyliw, Burt Kaliski, Panos Kampanakis, Jim
Turner, and Daniel Van Geest for their review and insightful Schaad, Robert Sparks, Sean Turner, and Daniel Van Geest for their
comments. They have greatly improved the design, clarity, and review and insightful comments. They have greatly improved the
implementation guidance. design, clarity, and implementation guidance.
The security properties provided by the mechanisms specified in this
document can be validated using formal methods. A ProVerif proof in
[H2019] shows that an attacker with a large-scale quantum computer
that is capable of breaking the Diffie-Hellman key agreement
algorithm cannot disrupt the delivery of the content-encryption key
to the recipient and the attacker cannot learn the content-encryption
key from the protocol exchange.
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. 33 change blocks. 
53 lines changed or deleted 74 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/