< draft-ietf-lamps-cms-mix-with-psk-01.txt   draft-ietf-lamps-cms-mix-with-psk-02.txt >
INTERNET-DRAFT R. Housley INTERNET-DRAFT R. Housley
Intended Status: Proposed Standard Vigil Security Intended Status: Proposed Standard Vigil Security
Expires: 19 May 2019 19 November 2018 Expires: 14 June 2019 14 December 2018
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-01.txt> <draft-ietf-lamps-cms-mix-with-psk-02.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 18 skipping to change at page 2, line 18
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Version Numbers . . . . . . . . . . . . . . . . . . . . 3 1.3. Version Numbers . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. KeyTransPSKRecipientInfo . . . . . . . . . . . . . . . . . . . 5 3. KeyTransPSKRecipientInfo . . . . . . . . . . . . . . . . . . . 6
4. KeyAgreePSKRecipientInfo . . . . . . . . . . . . . . . . . . . 6 4. KeyAgreePSKRecipientInfo . . . . . . . . . . . . . . . . . . . 7
5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9
6. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
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. It is an open question whether or not it is feasible to build
a large-scale quantum computer, and if so, when that might happen. a large-scale quantum computer, and if so, when that might happen.
However, if such a quantum computer is invented, many of the However, if such a quantum computer is invented, many of the
cryptographic algorithms and the security protocols that use them cryptographic algorithms and the security protocols that use them
would become vulnerable. would become vulnerable.
The Cryptographic Message Syntax (CMS) [RFC5652][RFC5803] supports The Cryptographic Message Syntax (CMS) [RFC5652][RFC5803] 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 [RFC4055], 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.
Once quantum-secure key management algorithms are available, the CMS Once quantum-secure key management algorithms are available, the CMS
will be extended to support them, if the existing syntax does not will be extended to support them, if the existing syntax does not
already accommodate the new algorithms. already accommodate the new algorithms.
In the near-term, this document describes a mechanism to protect In the near-term, this document describes a mechanism to protect
today's communication from the future invention of a large-scale today's communication from the future invention of a large-scale
quantum computer by mixing the output of existing key transport and quantum computer by mixing the output of existing key transport and
key agreement algorithms with a pre-shared key (PSK). Secure key agreement algorithms with a pre-shared key (PSK). Secure
communication can be achieved today by mixing a strong PSK with the communication can be achieved today by mixing a strong PSK with the
output of an existing key transport algorithm, like RSA [RFC4055], 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 invulnerable 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
besides protection against the future invention of a large-scale
quantum computer. For example, there is always the possibility of a
cryptoanalytic breakthrough on one or more of the classic public-key
algorithm, and there are longstanding concerns about undisclosed
trapdoors in Diffie-Hellamn parameters. Inclusion of a strong PSK as
part of the overall key management offer additional 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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. ASN.1 1.2. ASN.1
CMS values are generated using ASN.1 [X680], which uses the Basic CMS values are generated using ASN.1 [X680], which uses the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER) Encoding Rules (BER) and the Distinguished Encoding Rules (DER)
[X690]. [X690].
1.3. Version Numbers 1.3. Version Numbers
skipping to change at page 4, line 26 skipping to change at page 4, line 39
The CMS enveloped-data content type [RFC5652] and the CMS The CMS enveloped-data content type [RFC5652] and the CMS
authenticated-enveloped-data content type [RFC5083] support both key authenticated-enveloped-data content type [RFC5083] support both key
transport and key agreement public-key algorithms to establish the transport and key agreement public-key algorithms to establish the
key used to encrypt the content. No restrictions are imposed on the key used to encrypt the content. No restrictions are imposed on the
key transport or key agreement public-key algorithms, which means key transport or key agreement public-key algorithms, which means
that any key transport or key agreement algorithm can be used, that any key transport or key agreement algorithm can be used,
including algorithms that are specified in the future. In both including algorithms that are specified in the future. In both
cases, the sender randomly generates the content-encryption key, and cases, the sender randomly generates the content-encryption key, and
then all recipients obtain that key. All recipients use the sender- then all recipients obtain that key. All recipients use the sender-
generated symmetric 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-derivation key. In both cases, the PSK is mixed with symmetric key-encryption key, which is used to encrypt the sender-
the key-derivation key to create a quantum-resistant key-encryption generated content-encryption key. In both cases, the PSK is used as
key. The PSK MUST be distributed to the sender and all of the one of the inputs to a key-derivation function to create a quantum-
recipients by some out-of-band means that does not make it vulnerable resistant key-encryption key. The PSK MUST be distributed to the
to the future invention of a large-scale quantum computer, and an sender and all of the recipients by some out-of-band means that does
identifier MUST be assigned to the PSK. not make it vulnerable to the future invention of a large-scale
quantum computer, and an identifier MUST be assigned to the PSK.
The content-encryption key or content-authenticated-encryption key is The content-encryption key or content-authenticated-encryption key is
quantum-resistant, and it is established using these steps: quantum-resistant, and the sender establishes it using these steps:
1. The content-encryption key or the content-authenticated-encryption When using a key transport algorithm:
key is generated at random.
2. The key-derivation key is generated at random. 1. The content-encryption key or the content-authenticated-
encryption key, called CEK, is generated at random.
3. The key-encryption key is established for each recipient. The 2. The key-derivation key, called KDK, is generated at random.
details depend on the key management algorithm used:
key transport: the key-derivation key is encrypted in the 3. For each recipient, the KDK is encrypted in the recipient's
recipient's public key, then the key derivation function (KDF) public key, then the key derivation function (KDF) is used to
is used to mix the pre-shared key (PSK) and the key-derivation mix the pre-shared key (PSK) and the KDK to produce the key-
key to produce the key-encryption key; or encryption key, called KEK.
key agreement: the recipient's public key and the sender's 4. The KEK is used to encrypt the CEK.
private key are used to generate a pairwise symmetric key, then
the key derivation function (KDF) is used to mix the pre-shared
key (PSK) and the pairwise symmetric key to produce the key-
encryption key.
4. The key-encryption key is used to encrypt the content-encryption When using a key agreement algorithm:
key or content-authenticated-encryption key.
1. The content-encryption key or the content-authenticated-
encryption key, called CEK, is generated at random.
2. For each recipient, a pairwise key-encryption key, called KEK1,
is established using the recipient's public key and the
sender's private key.
3. For each recipient, the key derivation function (KDF) is used
to mix the pre-shared key (PSK) and the pairwise KEK1, and the
result is called KEK2.
4. For each recipient, the pairwise KEK2 is used to encrypt the
CEK.
As specified in Section 6.2.5 of [RFC5652], recipient information for As specified in Section 6.2.5 of [RFC5652], recipient information for
additional key management techniques are represented in the additional key management techniques are represented in the
OtherRecipientInfo type. Two key management techniques are specified OtherRecipientInfo type. Two key management techniques are specified
in this document, and they are each identified by a unique ASN.1 in this document, and they are each identified by a unique ASN.1
object identifier. object identifier.
The first key management technique, called keyTransPSK, see The first key management technique, called keyTransPSK, see
Section 3, uses a key transport algorithm to transfer the key- Section 3, uses a key transport algorithm to transfer the key-
derivation key from the sender to the recipient, and then the key- derivation key from the sender to the recipient, and then the key-
derivation key is mixed with the PSK using a KDF. The output of the derivation key is mixed with the PSK using a KDF. The output of the
KDF is the key-encryption key for the encryption of the content- KDF is the key-encryption key, which is used for the encryption of
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 used to encrypt the key-derivation key, key-encryption key, which is then mixed with the PSK using a KDF to
and the then key-derivation key is mixed with the PSK using a KDF. produce a second pairwise key-encryption key, which is then used to
The output of the KDF is the key-encryption key for the encryption of encrypt the content-encryption key or content-authenticated-
the content-encryption key or content-authenticated-encryption key. encryption key.
3. KeyTransPSKRecipientInfo 3. KeyTransPSKRecipientInfo
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.
skipping to change at page 7, line 36 skipping to change at page 8, line 9
version is the syntax version number. The version MUST be 0. The version is the syntax version number. The version MUST be 0. The
CMSVersion type is described in Section 10.2.5 of [RFC5652]. CMSVersion type is described in Section 10.2.5 of [RFC5652].
pskid is the identifier of the PSK used by the sender. The pskid is the identifier of the PSK used by the sender. The
identifier is an OCTET STRING, and it need not be human readable. identifier is an OCTET STRING, and it need not be human readable.
originator is a CHOICE with three alternatives specifying the originator is a CHOICE with three alternatives specifying the
sender's key agreement public key. Implementations MUST support sender's key agreement public key. Implementations MUST support
all three alternatives for specifying the sender's public key. all three alternatives for specifying the sender's public key.
The sender uses their own private key and the recipient's public The sender uses their own private key and the recipient's public
key to generate a pairwise symmetric secret value. A key key to generate a pairwise key-encryption key. A key derivation
derivation function (KDF) is used to mix the PSK and the pairwise function (KDF) is used to mix the PSK and the pairwise key-
symmetric secret value to produce a key-encryption key. The encryption key to produce a second key-encryption key. The
OriginatorIdentifierOrKey type is described in Section 6.2.2 of OriginatorIdentifierOrKey type is described in Section 6.2.2 of
[RFC5652]. [RFC5652].
ukm is optional. With some key agreement algorithms, the sender ukm is optional. With some key agreement algorithms, the sender
provides a User Keying Material (UKM) to ensure that a different provides a User Keying Material (UKM) to ensure that a different
key is generated each time the same two parties generate a key is generated each time the same two parties generate a
pairwise key. Implementations MUST accept a pairwise key. Implementations MUST accept a
KeyAgreePSKRecipientInfo SEQUENCE that includes a ukm field. KeyAgreePSKRecipientInfo SEQUENCE that includes a ukm field.
Implementations that do not support key agreement algorithms that Implementations that do not support key agreement algorithms that
make use of UKMs MUST gracefully handle the presence of UKMs. The make use of UKMs MUST gracefully handle the presence of UKMs. The
UserKeyingMaterial type is described in Section 10.2.6 of UserKeyingMaterial type is described in Section 10.2.6 of
[RFC5652]. [RFC5652].
kdfAlgorithm identifies the key-derivation algorithm, and any kdfAlgorithm identifies the key-derivation algorithm, and any
associated parameters, used by the sender to mix the pairwise key associated parameters, used by the sender to mix the pairwise key-
and the PSK. The pairwise key input to the key-derivation encryption key and the PSK to produce a second key-encryption key
algorithm MUST be the same length as the key-encryption key that of the same length as the first one. The
will be the output by the key-derivation algorithm. The
KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of
[RFC5652]. [RFC5652].
keyEncryptionAlgorithm identifies a key-encryption algorithm used keyEncryptionAlgorithm identifies a key-encryption algorithm used
to encrypt the content-encryption key or the content- to encrypt the content-encryption key or the content-
authenticated-encryption key. The authenticated-encryption key. The
KeyEncryptionAlgorithmIdentifier type is described in Section KeyEncryptionAlgorithmIdentifier type is described in Section
10.1.3 of [RFC5652]. 10.1.3 of [RFC5652].
recipientEncryptedKeys includes a recipient identifier and recipientEncryptedKeys includes a recipient identifier and
encrypted key for one or more recipients. The encrypted key for one or more recipients. The
KeyAgreeRecipientIdentifier is a CHOICE with two alternatives KeyAgreeRecipientIdentifier is a CHOICE with two alternatives
specifying the recipient's certificate, and thereby the specifying the recipient's certificate, and thereby the
recipient's public key, that was used by the sender to generate a recipient's public key, that was used by the sender to generate a
pairwise key. The encryptedKey is the result of encrypting the pairwise key-encryption key. The encryptedKey is the result of
content-encryption key or the content-authenticated-encryption key encrypting the content-encryption key or the content-
with the key-encryption key. EncryptedKey is an OCTET STRING. authenticated-encryption key with the second pairwise key-
The RecipientEncryptedKeys type is defined in Section 6.2.2 of encryption key. EncryptedKey is an OCTET STRING. The
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 make use fo a hash function.
A KDF has several inout 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 PSK to the KDF. For KeyTransPSKRecipientInfo, it is the PSK
concatenated with the key-derivation key. For concatenated with the key-derivation key. For
KeyAgreePSKRecipientInfo, it is the PSK concatenated with the KeyAgreePSKRecipientInfo, it is the PSK concatenated with the
pairwise symmetric secret value produced by the key agreement pairwise key-encryption key produced by the key agreement
algorithm. algorithm.
salt is an optional non-secret random value. The salt is not salt is an optional non-secret random value. The salt is not
used. used.
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
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. Note that EXPLICIT tagging is used in the ASN.1 module value. Note that EXPLICIT tagging is used in the ASN.1 module
that deines this structure. For KeyTransPSKRecipientInfo, the that deines this 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 ENUMERATED value of 10 is used. CMSORIforPSKOtherInfo is defined
by the following ASN.1 structure: by the following ASN.1 structure:
CMSORIforPSKOtherInfo ::= SEQUENCE { CMSORIforPSKOtherInfo ::= SEQUENCE {
skipping to change at page 9, line 48 skipping to change at page 10, line 22
which identifies the algorithm and provides algorithm parameters, which identifies the algorithm and provides algorithm parameters,
if any. if any.
pskLength is a positive integer; it contains the length of the PSK pskLength is a positive integer; it contains the length of the PSK
in octets. in octets.
kdkLength is a positive integer; it contains the length of the kdkLength is a positive integer; it contains the length of the
key-derivation key in octets. For KeyTransPSKRecipientInfo, the key-derivation key in octets. For KeyTransPSKRecipientInfo, the
key-derivation key is generated by the sender. For key-derivation key is generated by the sender. For
KeyAgreePSKRecipientInfo, the key-derivation key is the pairwise KeyAgreePSKRecipientInfo, the key-derivation key is the pairwise
symmetric 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. OKM is the key-encryption key that is used to encrypt the content-
encryption key or the content-authenticated-encryption key.
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 [RFC5911] and [RFC5912].
CMSORIforPSK-2017 CMSORIforPSK-2017
{ 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-2017(TBD0) } smime(16) modules(0) id-mod-cms-ori-psk-2017(TBD0) }
skipping to change at page 12, line 48 skipping to change at page 13, line 10
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
256 bits in length. Similarly, the content-encryption key or 256 bits in length. Similarly, the content-encryption key or
content-authenticated-encryption key needs to be at least 256 bits in content-authenticated-encryption key needs to be at least 256 bits in
length. length.
Implementations must randomly generate key-derivation keys as well as
the content-encryption keys or content-authenticated-encryption keys.
Also, the generation of public/private key pairs for the key
transport and key agreement algorithms rely on a random numbers. The
use of inadequate pseudo-random number generators (PRNGs) to generate
cryptographic keys can result in little or no security. An attacker
may find it much easier to reproduce the PRNG environment that
produced the keys, searching the resulting small set of
possibilities, rather than brute force searching the whole key space.
The generation of quality random numbers is difficult. [RFC4086]
offers important guidance in this area.
When using a PSK with a key transport or a key agreement algorithm, a When using a PSK with a key transport or a key agreement algorithm, a
key-encryption key is produced to encrypt the content-encryption key key-encryption key is produced to encrypt the content-encryption key
or content-authenticated-encryption key. If the key-encryption or content-authenticated-encryption key. If the key-encryption
algorithm is different than the algorithm used to protect the algorithm is different than the algorithm used to protect the
content, then the effective security is determined by the weaker of content, then the effective security is determined by the weaker of
the two algorithms. If, for example, content is encrypted with the two algorithms. If, for example, content is encrypted with
256-bit AES, and the key is wrapped with 128-bit AES, then at most 256-bit AES, and the key is wrapped with 128-bit AES, then at most
128 bits 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.
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.
Sound cryptographic key hygiene is to use a key for one and only one
purpose. Use of the recipient's public key for both the traditional
CMS and the PSK-mixing variation specified in this document would be
a violations of this principle; however, there is no known way for an
attacker to take advantage of this situation. However, an
application should enforce separation whenever possible. For
example, an purpose identifier for use in the X.509 extended key
usage certificate extension [RFC5280] could be identified in the
future to indicate that a public key should only be used in
conjunction with a PSK, or only without.
Implementations must randomly generate key-derivation keys as well as
the content-encryption keys or content-authenticated-encryption keys.
Also, the generation of public/private key pairs for the key
transport and key agreement algorithms rely on a random numbers. The
use of inadequate pseudo-random number generators (PRNGs) to generate
cryptographic keys can result in little or no security. An attacker
may find it much easier to reproduce the PRNG environment that
produced the keys, searching the resulting small set of
possibilities, rather than brute force searching the whole key space.
The generation of quality random numbers is difficult. [RFC4086]
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, implementors should be prepared for
the set of supported algorithms to change over time. the set of supported algorithms to change over time.
8. Privacy Considerations 8. Privacy Considerations
skipping to change at page 15, line 46 skipping to change at page 16, line 25
RFC 2631, June 1999. RFC 2631, June 1999.
[RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport
Algorithm in Cryptographic Message Syntax (CMS)", Algorithm in Cryptographic Message Syntax (CMS)",
RFC 3560, July 2003. RFC 3560, July 2003.
[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.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(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 [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.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, November 2016.
Acknowledgements Acknowledgements
Many thanks to Burt Kaliski, Panos Kampanakis, Jim Schaad, Sean Many thanks to Burt Kaliski, Panos Kampanakis, Jim Schaad, Sean
Turner, and Daniel Van Geest for their review and insightful Turner, and Daniel Van Geest for their review and insightful
comments. They have greatly improved the design, clarity, and comments. They have greatly improved the design, clarity, and
implementation guidance. implementation guidance.
Author's Address Author's Address
Russell Housley Russell Housley
 End of changes. 34 change blocks. 
78 lines changed or deleted 117 lines changed or added

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