< draft-ietf-lamps-cms-mix-with-psk-00.txt   draft-ietf-lamps-cms-mix-with-psk-01.txt >
INTERNET-DRAFT R. Housley INTERNET-DRAFT R. Housley
Intended Status: Proposed Standard Vigil Security Intended Status: Proposed Standard Vigil Security
Expires: 17 March 2019 17 September 2018 Expires: 19 May 2019 19 November 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-00.txt> <draft-ietf-lamps-cms-mix-with-psk-01.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
quantum-secure key management algorithms are available, the CMS will quantum-secure key management algorithms are available, the CMS will
be extended to support them, if existing syntax the does not be extended to support the new algorithms, if the existing syntax
accommodated them. In the near-term, this document describes a does not accommodate them. In the near-term, this document describes
mechanism to protect today's communication from the future invention a mechanism to protect today's communication from the future
of a large-scale quantum computer by mixing the output of key invention of a large-scale quantum computer by mixing the output of
transport and key agreement algorithms with a pre-shared key. key transport and key agreement algorithms with a pre-shared key.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Version Numbers . . . . . . . . . . . . . . . . . . . . . 3 1.3. Version Numbers . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. KeyTransPSKRecipientInfo . . . . . . . . . . . . . . . . . . . 5 3. KeyTransPSKRecipientInfo . . . . . . . . . . . . . . . . . . . 5
4. KeyAgreePSKRecipientInfo . . . . . . . . . . . . . . . . . . . 7 4. KeyAgreePSKRecipientInfo . . . . . . . . . . . . . . . . . . . 6
5. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13
9. Informative References . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
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.
skipping to change at page 3, line 4 skipping to change at page 3, line 6
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 [RFC4055], 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 current syntax the does not will be extended to support them, if the existing syntax does not
accommodated them. 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 with a strong PSK with communication can be achieved today by mixing a strong PSK with the
the output of an existing key transport algorithm, like RSA output of an existing key transport algorithm, like RSA [RFC4055], or
[RFC4055], or an existing key agreement algorithm, like Diffie- an existing key agreement algorithm, like Diffie-Hellman [RFC2631] or
Hellman [RFC2631] or Elliptic Curve Diffie-Hellman [RFC5753]. A Elliptic Curve Diffie-Hellman [RFC5753]. A security solution that is
security solution that is believed to be quantum resistant can be believed to be quantum resistant can be achieved by using a PSK with
achieved by using a PSK with sufficient entropy along with a quantum sufficient entropy along with a quantum resistant key derivation
resistant key derivation function (KDF), like HKDF [RFC5869], and a function (KDF), like HKDF [RFC5869], and a quantum resistant
quantum resistant encryption algorithm, like 256-bit AES [AES]. In encryption algorithm, like 256-bit AES [AES]. In this way, today's
this way, today's CMS-protected communication can be invulnerable to CMS-protected communication can be invulnerable to an attacker with a
an attacker with a large-scale quantum computer. large-scale quantum computer.
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 3, line 51 skipping to change at page 4, line 4
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
The major data structures include a version number as the first item The major data structures include a version number as the first item
in the data structure. The version number is intended to avoid ASN.1 in the data structure. The version number is intended to avoid ASN.1
decode errors. Some implementations do not check the version number decode errors. Some implementations do not check the version number
prior to attempting a decode, and then if a decode error occurs, the prior to attempting a decode, and then if a decode error occurs, the
version number is checked as part of the error handling routine. version number is checked as part of the error handling routine.
This is a reasonable approach; it places error processing outside of This is a reasonable approach; it places error processing outside of
the fast path. This approach is also forgiving when an incorrect the fast path. This approach is also forgiving when an incorrect
version number is used by the sender. version number is used by the sender.
Whenever the structure is updated, a higher version number will be Whenever the structure is updated, a higher version number will be
assigned. However, to ensure maximum interoperability, the higher assigned. However, to ensure maximum interoperability, the higher
version number is only used when the new syntax feature is employed. version number is only used when the new syntax feature is employed.
That is, the lowest version number that supports the generated syntax That is, the lowest version number that supports the generated syntax
is used. is used.
2. Overview 2. Overview
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. In both cases, the sender randomly key used to encrypt the content. No restrictions are imposed on the
generates the key, and then all recipients obtain that key. For key transport or key agreement public-key algorithms, which means
enveloped-data, a content-encryption key is established. For that any key transport or key agreement algorithm can be used,
authenticated-enveloped-data, a content-authenticated-encryption key including algorithms that are specified in the future. In both
is established. All recipients use the sender-generated symmetric cases, the sender randomly generates the content-encryption key, and
key for decryption. then all recipients obtain that key. All recipients use the sender-
generated symmetric key for decryption.
This specification defines two quantum-resistant ways to establish This specification defines two quantum-resistant ways to establish a
these symmetric keys. In both cases, a PSK MUST be distributed to symmetric key-derivation key. In both cases, the PSK is mixed with
the sender and all of the recipients by some out-of-band means that the key-derivation key to create a quantum-resistant key-encryption
does not make it vulnerable to the future invention of a large-scale key. The PSK MUST be distributed to the sender and all of the
quantum computer, and an identifier MUST be assigned to the PSK. recipients by some out-of-band means that does 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
established by following these steps: quantum-resistant, and it is established using these steps:
1. The content-encryption key or the content-authenticated-encryption 1. The content-encryption key or the content-authenticated-encryption
key is generated at random. key is generated at random.
2. The key-derivation key is generated at random. 2. The key-derivation key is generated at random.
3. The key-encryption key is established for each recipient. The 3. The key-encryption key is established for each recipient. The
details depend on the key management algorithm used: details depend on the key management algorithm used:
key transport: the key-derivation key is encrypted in the key transport: the key-derivation key is encrypted in the
recipient's public key, then the key derivation function (KDF) recipient's public key, then the key derivation function (KDF)
is used to mix the pre-shared key (PSK) and the key-derivation is used to mix the pre-shared key (PSK) and the key-derivation
key to produce the key-encryption key; or key to produce the key-encryption key; or
key agreement: the recipient's public key and the sender's key agreement: the recipient's public key and the sender's
private key are used to generate a pairwise symmetric key, then private key are used to generate a pairwise symmetric key, then
the key derivation function (KDF) is used to mix the pre-shared the key derivation function (KDF) is used to mix the pre-shared
key (PSK) and the pairwise symmetric key to produce the key- key (PSK) and the pairwise symmetric key to produce the key-
encryption key. encryption key.
4. The key-encryption key is used to encrypt the content-encryption 4. The key-encryption key is used to encrypt the content-encryption
skipping to change at page 7, line 28 skipping to change at page 7, line 35
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 the corresponding private key and the recipient's The sender uses their own private key and the recipient's public
public key to generate a pairwise key. A key derivation function key to generate a pairwise symmetric secret value. A key
(KDF) is used to mix the PSK and the pairwise key to produce a derivation function (KDF) is used to mix the PSK and the pairwise
key-encryption key. The OriginatorIdentifierOrKey type is symmetric secret value to produce a key-encryption key. The
described in Section 6.2.2 of [RFC5652]. OriginatorIdentifierOrKey type is described in Section 6.2.2 of
[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 KeyDerivationAlgorithmIdentifier is described in and the PSK. The pairwise key input to the key-derivation
Section 10.1.6 of [RFC5652]. algorithm MUST be the same length as the key-encryption key that
will be the output by the key-derivation algorithm. The
KeyDerivationAlgorithmIdentifier is described in Section 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 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. The encryptedKey is the result of encrypting the
content-encryption key or the content-authenticated-encryption key content-encryption key or the content-authenticated-encryption key
with the key-encryption key. EncryptedKey is an OCTET STRING. with the key-encryption key. EncryptedKey is an OCTET STRING.
The RecipientEncryptedKeys type is defined in Section 6.2.2 of The RecipientEncryptedKeys type is defined in Section 6.2.2 of
[RFC5652]. [RFC5652].
5. ASN.1 Module 5. Key Derivation
Many key derivation functions (KDFs) internally employ a one-way hash
function. When this is the case, the hash function that is used is
identified by the KeyDerivationAlgorithmIdentifier. HKDF [RFC5869]
is one example of a KDF that make use fo a hash function.
A KDF has several inout values. This section describes the
conventions for using the KDF to compute the key-encryption key for
KeyTransPSKRecipientInfo and KeyAgreePSKRecipientInfo. For
simplicity, the terminology used in the HKDF [RFC5869] specification
is used here.
The KDF inputs are:
IKM is the input keying material; it is the symmetric secret input
to the KDF. For KeyTransPSKRecipientInfo, it is the PSK
concatenated with the key-derivation key. For
KeyAgreePSKRecipientInfo, it is the PSK concatenated with the
pairwise symmetric secret value produced by the key agreement
algorithm.
salt is an optional non-secret random value. The salt is not
used.
L is the length of output keying material in octets; the value
depends on the key-encryption algorithm that will be used. The
algorithm is identified by the KeyEncryptionAlgorithmIdentifier.
In addition, the OBJECT IDENTIFIER portion of the
KeyEncryptionAlgorithmIdentifier is included in the next input,
called info.
info is optional context and application specific information.
The DER-encoding of CMSORIforPSKOtherInfo is used as the info
value. Note that EXPLICIT tagging is used in the ASN.1 module
that deines this structure. For KeyTransPSKRecipientInfo, the
ENUMERATED value of 5 is used. For KeyAgreePSKRecipientInfo, the
ENUMERATED value of 10 is used. CMSORIforPSKOtherInfo is defined
by the following ASN.1 structure:
CMSORIforPSKOtherInfo ::= SEQUENCE {
keyMgmtAlgType ENUMERATED {
keyTrans (5),
keyAgree (10) },
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
pskLength INTEGER (1..MAX),
kdkLength INTEGER (1..MAX) }
The fields of type CMSORIforPSKOtherInfo have the following meanings:
keyMgmtAlgType is either set to 5 or 10. For
KeyTransPSKRecipientInfo, the ENUMERATED value of 5 is used. For
KeyAgreePSKRecipientInfo, the ENUMERATED value of 10 is used.
keyEncryptionAlgorithm is the KeyEncryptionAlgorithmIdentifier,
which identifies the algorithm and provides algorithm parameters,
if any.
pskLength is a positive integer; it contains the length of the PSK
in octets.
kdkLength is a positive integer; it contains the length of the
key-derivation key in octets. For KeyTransPSKRecipientInfo, the
key-derivation key is generated by the sender. For
KeyAgreePSKRecipientInfo, the key-derivation key is the pairwise
symmetric key produced by the key agreement algorithm.
The KDF output is:
OKM is the output keying material, which is exactly L octets. The
OKM is the key-encryption key.
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) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- EXPORTS All
IMPORTS IMPORTS
AlgorithmIdentifier{}, KEY-DERIVATION AlgorithmIdentifier{}, KEY-DERIVATION
FROM AlgorithmInformation-2009 -- [RFC5912] FROM AlgorithmInformation-2009 -- [RFC5912]
{ 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)
skipping to change at page 10, line 4 skipping to change at page 11, line 37
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 ORI-TYPE ::= {
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,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys RecipientEncryptedKeys } recipientEncryptedKeys RecipientEncryptedKeys }
--
-- Structure to provide 'info' input to the KDF
--
CMSORIforPSKOtherInfo ::= SEQUENCE {
keyMgmtAlgType ENUMERATED {
keyTrans (5),
keyAgree (10) },
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
pskLength INTEGER (1..MAX),
kdkLength INTEGER (1..MAX) }
END END
6. Security Considerations 7. Security Considerations
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, 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
skipping to change at page 12, line 5 skipping to change at page 13, line 46
vulnerable to the future invention of a large-scale quantum computer. vulnerable to the future invention of a large-scale quantum computer.
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.
7. IANA Considerations 8. Privacy Considerations
An observer can see which parties are using each PSK simply by
watching the PSK key identifiers. However, the addition of these key
identifiers is not really making privacy worse. When key transport
is used, the RecipientIdentifier is always present, and it clearly
identifies each recipient to an observer. When key agreement is
used, either the IssuerAndSerialNumber or the RecipientKeyIdentifier
is always present, and these clearly identify each recipient.
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 the Section 5 was
assigned in the SMI Security for S/MIME Module Identifiers assigned 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-2017 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 object identifier for an arc to assign Other Recipient Info
skipping to change at page 12, line 34 skipping to change at page 14, line 37
following two entries with references to this document: following two entries 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 }
8. Normative References 10. 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.
skipping to change at page 13, line 10 skipping to change at page 15, line 17
[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.
9. 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-03, February 2018. c2pq-03, February 2018.
[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-13.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
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)", RFC Algorithm in Cryptographic Message Syntax (CMS)",
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, June "Randomness Requirements for Security", RFC 4086,
2005. June 2005.
[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, May Expand Key Derivation Function (HKDF)", RFC 5869,
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.
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 and implementation comments. They have greatly improved the design, clarity, and
guidance. implementation guidance.
Author's Address Author's Address
Russell Housley Russell Housley
Vigil Security, LLC Vigil Security, LLC
918 Spring Knoll Drive 516 Dranesville Road
Herndon, VA 20170 Herndon, VA 20170
USA USA
EMail: housley@vigilsec.com EMail: housley@vigilsec.com
 End of changes. 28 change blocks. 
67 lines changed or deleted 175 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/