draft-ietf-lamps-cms-shakes-05.txt   draft-ietf-lamps-cms-shakes-06.txt 
LAMPS WG Q. Dang LAMPS WG P. Kampanakis
Internet-Draft NIST Internet-Draft Cisco Systems
Intended status: Standards Track P. Kampanakis Intended status: Standards Track Q. Dang
Expires: June 21, 2019 Cisco Systems Expires: July 18, 2019 NIST
December 18, 2018 January 14, 2019
Use of the SHAKE One-way Hash Functions in the Cryptographic Message Use of the SHAKE One-way Hash Functions in the Cryptographic Message
Syntax (CMS) Syntax (CMS)
draft-ietf-lamps-cms-shakes-05 draft-ietf-lamps-cms-shakes-06
Abstract Abstract
This document describes the conventions for using the SHAKE family of This document describes the conventions for using the SHAKE family of
hash functions with the Cryptographic Message Syntax (CMS) as one-way hash functions with the Cryptographic Message Syntax (CMS) as one-way
hash functions with the RSA Probabilistic signature and ECDSA hash functions with the RSA Probabilistic signature and ECDSA
signature algorithms, as message digests and message authentication signature algorithms, as message digests and message authentication
codes. The conventions for the associated signer public keys in CMS codes. The conventions for the associated signer public keys in CMS
are also described. are also described.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 21, 2019. This Internet-Draft will expire on July 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
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. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Message Digests . . . . . . . . . . . . . . . . . . . . . 6 4.1. Message Digests . . . . . . . . . . . . . . . . . . . . . 6
4.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 6 4.2.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 7
4.2.2. Deterministic ECDSA Signatures . . . . . . . . . . . 7 4.2.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 7
4.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Message Authentication Codes . . . . . . . . . . . . . . 8 4.4. Message Authentication Codes . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Change Log 1. Change Log
[ EDNOTE: Remove this section before publication. ] [ EDNOTE: Remove this section before publication. ]
o draft-ietf-lamps-pkix-shake-06:
* Incorporated Eric's suggestion from WGLC.
o draft-ietf-lamps-cms-shake-05: o draft-ietf-lamps-cms-shake-05:
* Added informative references. * Added informative references.
* Updated ASN.1 so it compiles. * Updated ASN.1 so it compiles.
* Updated IANA considerations. * Updated IANA considerations.
o draft-ietf-lamps-cms-shake-04: o draft-ietf-lamps-cms-shake-04:
skipping to change at page 4, line 12 skipping to change at page 4, line 19
This specification describes the use of the SHAKE128 and SHAKE256 This specification describes the use of the SHAKE128 and SHAKE256
specified in [SHA3] as new hash functions in CMS. In addition, it specified in [SHA3] as new hash functions in CMS. In addition, it
describes the use of these functions with the RSASSA-PSS signature describes the use of these functions with the RSASSA-PSS signature
algorithm [RFC8017] and the Elliptic Curve Digital Signature algorithm [RFC8017] and the Elliptic Curve Digital Signature
Algorithm (ECDSA) [X9.62] with the CMS signed-data content type. Algorithm (ECDSA) [X9.62] with the CMS signed-data content type.
In the SHA-3 family, two extendable-output functions (SHAKEs), In the SHA-3 family, two extendable-output functions (SHAKEs),
SHAKE128 and SHAKE256, are defined. Four other hash function SHAKE128 and SHAKE256, are defined. Four other hash function
instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are also instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are also
defined but are out of scope for this document. A SHAKE is a defined but are out of scope for this document. A SHAKE is a
variable length hash function. The output length, in bits, of a variable length hash function defined as SHAKE(M, d) where the output
SHAKE is defined by the d parameter. The corresponding collision and is a d-bits long digest of message M. The corresponding collision
second preimage resistance strengths for SHAKE128 are min(d/2,128) and second preimage resistance strengths for SHAKE128 are
and min(d,128) bits respectively. And, the corresponding collision min(d/2,128) and min(d,128) bits respectively. And, the
and second preimage resistance strengths for SHAKE256 are corresponding collision and second preimage resistance strengths for
min(d/2,256) and min(d,256) bits respectively. SHAKE256 are min(d/2,256) and min(d,256) bits respectively.
A SHAKE can be used in CMS as the message digest function (to hash A SHAKE can be used in CMS as the message digest function (to hash
the message to be signed) in RSASSA-PSS and deterministic ECDSA, the message to be signed) in RSASSA-PSS and ECDSA, message
message authentication code and as the mask generating function in authentication code and as the mask generating function in RSASSA-
RSASSA-PSS. This specification describes the identifiers for SHAKEs PSS. This specification describes the identifiers for SHAKEs to be
to be used in CMS and their meaning. used in CMS and their meaning.
2.1. Terminology 2.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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Identifiers 3. Identifiers
skipping to change at page 5, line 34 skipping to change at page 5, line 42
id-ecdsa-with-SHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-ecdsa-with-SHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) 3 TBD } nistAlgorithm(4) 3 TBD }
id-ecdsa-with-SHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-ecdsa-with-SHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) 3 TBD } nistAlgorithm(4) 3 TBD }
[ EDNOTE: "TBD" will be specified by NIST. ] [ EDNOTE: "TBD" will be specified by NIST. ]
The parameters for the four RSASSA-PSS and deterministic ECDSA The parameters for the four RSASSA-PSS and ECDSA identifiers MUST be
identifiers MUST be absent. That is, each identifier SHALL be a absent. That is, each identifier SHALL be a SEQUENCE of one
SEQUENCE of one component, the OID. component, the OID.
Two new object identifiers for KMACs using SHAKE128 and SHAKE256 are Two new object identifiers for KMACs using SHAKE128 and SHAKE256 are
define elow. defined below.
id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) 2 19 } nistAlgorithm(4) 2 19 }
id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) 2 20 } nistAlgorithm(4) 2 20 }
The parameters for id-KmacWithSHAKE128 and id-KmacWithSHAKE256 MUST The parameters for id-KmacWithSHAKE128 and id-KmacWithSHAKE256 MUST
be absent. That is, each identifier SHALL be a SEQUENCE of one be absent. That is, each identifier SHALL be a SEQUENCE of one
component, the OID. component, the OID.
Section 4.1, Section 4.2.1, Section 4.2.2 and Section 4.4 specify the Section 4.1, Section 4.2.1, Section 4.2.2 and Section 4.4 specify the
required output length for each use of SHAKE128 or SHAKE256 in required output length for each use of SHAKE128 or SHAKE256 in
message digests, RSASSA-PSS, determinstic ECDSA and KMAC. message digests, RSASSA-PSS, ECDSA and KMAC.
4. Use in CMS 4. Use in CMS
4.1. Message Digests 4.1. Message Digests
The id-shake128-len and id-shake256-len OIDs (Section 3) can be used The id-shake128-len and id-shake256-len OIDs (Section 3) can be used
as the digest algorithm identifiers located in the SignedData, as the digest algorithm identifiers located in the SignedData,
SignerInfo, DigestedData, and the AuthenticatedData digestAlgorithm SignerInfo, DigestedData, and the AuthenticatedData digestAlgorithm
fields in CMS [RFC5652]. The encoding MUST omit the parameters field fields in CMS [RFC5652]. The encoding MUST omit the parameters field
and the output size, d, for the SHAKE128 or SHAKE256 message digest and the output size, d, for the SHAKE128 or SHAKE256 message digest
skipping to change at page 6, line 33 skipping to change at page 6, line 45
values are input to signature algorithms. The digest algorithm MUST values are input to signature algorithms. The digest algorithm MUST
be the same as the message hash algorithms used in signatures. be the same as the message hash algorithms used in signatures.
4.2. Signatures 4.2. Signatures
In CMS, signature algorithm identifiers are located in the SignerInfo In CMS, signature algorithm identifiers are located in the SignerInfo
signatureAlgorithm field of SignedData content type and signatureAlgorithm field of SignedData content type and
countersignature attribute. Signature values are located in the countersignature attribute. Signature values are located in the
SignerInfo signature field of SignedData and countersignature. SignerInfo signature field of SignedData and countersignature.
Conforming implementations that process RSASSA-PSS and deterministic Conforming implementations that process RSASSA-PSS and ECDSA with
ECDSA with SHAKE signatures when processing CMS data MUST recognize SHAKE signatures when processing CMS data MUST recognize the
the corresponding OIDs specified in Section 3. corresponding OIDs specified in Section 3.
4.2.1. RSASSA-PSS Signatures 4.2.1. RSASSA-PSS Signatures
The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA-
PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 3 is PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 3 is
used, the encoding MUST omit the parameters field. That is, the used, the encoding MUST omit the parameters field. That is, the
AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA-
PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA- PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA-
PSS-params that are used to define the algorithms and inputs to the PSS-params that are used to define the algorithms and inputs to the
algorithm. This specification does not use parameters because the algorithm. This specification does not use parameters because the
skipping to change at page 7, line 15 skipping to change at page 7, line 31
64 bytes respectively. 64 bytes respectively.
The mask generation function takes an octet string of variable length The mask generation function takes an octet string of variable length
and a desired output length as input, and outputs an octet string of and a desired output length as input, and outputs an octet string of
the desired length. In RSASSA-PSS with SHAKES, the SHAKEs MUST be the desired length. In RSASSA-PSS with SHAKES, the SHAKEs MUST be
used natively as the MGF function, instead of the MGF1 algorithm that used natively as the MGF function, instead of the MGF1 algorithm that
uses the hash function in multiple iterations as specified in uses the hash function in multiple iterations as specified in
Section B.2.1 of [RFC8017]. In other words, the MGF is defined as Section B.2.1 of [RFC8017]. In other words, the MGF is defined as
the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS- the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS-
SHAKE128 and id-RSASSA-PSS-SHAKE256 respectively. The mgfSeed is the SHAKE128 and id-RSASSA-PSS-SHAKE256 respectively. The mgfSeed is the
seed from which mask is generated, an octet string [RFC8017]. The seed from which mask is generated, an octet string [RFC8017]. As
output length is (n - 264)/8 or (n - 520)/8 bytes respectively, where explained in Step 9 of section 9.1.1 of [RFC8017], the output length
n is the RSA modulus in bits. For example, when RSA modulus n is of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message
2048, the output length of SHAKE128 or SHAKE256 as the MGF will be length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32
223 or 191-bits when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 and 64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256
is used respectively. respectively. Thus when SHAKE is used as the MGF, the SHAKE output
length maskLen is (n - 264) or (n - 520) bits respectively. For
example, when RSA modulus n is 2048, the output length of SHAKE128 or
SHAKE256 as the MGF will be 1784 or 1528-bits when id-RSASSA-PSS-
SHAKE128 or id-RSASSA-PSS-SHAKE256 is used respectively.
The RSASSA-PSS saltLength MUST be 32 or 64 bytes respectively. The RSASSA-PSS saltLength MUST be 32 or 64 bytes respectively.
Finally, the trailerField MUST be 1, which represents the trailer Finally, the trailerField MUST be 1, which represents the trailer
field with hexadecimal value 0xBC [RFC8017]. field with hexadecimal value 0xBC [RFC8017].
4.2.2. Deterministic ECDSA Signatures 4.2.2. ECDSA Signatures
The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
[X9.62]. When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256 [X9.62]. When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256
(specified in Section 3) algorithm identifier appears, the respective (specified in Section 3) algorithm identifier appears, the respective
SHAKE function is used as the hash. The encoding MUST omit the SHAKE function is used as the hash. The encoding MUST omit the
parameters field. That is, the AlgorithmIdentifier SHALL be a parameters field. That is, the AlgorithmIdentifier SHALL be a
SEQUENCE of one component, the OID id-ecdsa-with-SHAKE128 or id- SEQUENCE of one component, the OID id-ecdsa-with-SHAKE128 or id-
ecdsa-with-SHAKE256. ecdsa-with-SHAKE256.
For simplicity and compliance with the ECDSA standard specification, For simplicity and compliance with the ECDSA standard specification,
the output size of the hash function must be explicitly determined. the output size of the hash function must be explicitly determined.
The output size, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be The output size, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be
256 or 512 bits respectively. 256 or 512 bits respectively.
Conforming implementations that generate ECDSA with SHAKE signatures It is RECOMMENDED that conforming implementations that generate ECDSA
in CMS MUST generate such signatures with a deterministicly with SHAKE signatures in CMS generate such signatures with a
generated, non-random k in accordance with all the requirements deterministically generated, non-random k in accordance with all the
specified in [RFC6979]. They MAY also generate such signatures in requirements specified in [RFC6979]. They MAY also generate such
accordance with all other recommendations in [X9.62] or [SEC1] if signatures in accordance with all other recommendations in [X9.62] or
they have a stated policy that requires conformance to these [SEC1] if they have a stated policy that requires conformance to
standards. these standards.
4.3. Public Keys 4.3. Public Keys
In CMS, the signer's public key algorithm identifiers are located in In CMS, the signer's public key algorithm identifiers are located in
the OriginatorPublicKey's algorithm attribute. the OriginatorPublicKey's algorithm attribute. The conventions and
encoding for RSASSA-PSS and ECDSA public keys algorithm identifiers
are as specified in Section 2.3 of [RFC3279], Section 3.1 of
[RFC4055] and Section 2.1 of [RFC5480].
Conforming implementations MUST specify the algorithms explicitly by Traditionally, the rsaEncryption object identifier is used to
using the OIDs specified in Section 3 when encoding RSASSA-PSS with identify RSA public keys. The rsaEncryption object identifier
SHAKE public keys in CMS messages. The conventions and encoding for continues to identify the public key when the RSA private key owner
RSASSA-PSS and ECDSA public keys algorithm identifiers are as does not wish to limit the use of the public key exclusively to
specified in Section 2.3 of [RFC3279], Section 3.1 of [RFC4055] and RSASSA-PSS with SHAKEs. When the RSA private key owner wishes to
Section 2.1 of [RFC5480]. limit the use of the public key exclusively to RSASSA-PSS, the
AlgorithmIdentifier for RSASSA-PSS defined in Section 3 SHOULD be
used as the algorithm attribute in the OriginatorPublicKey sequence.
Conforming client implementations that process RSASSA-PSS with SHAKE
public keys in CMS message MUST recognize the corresponding OIDs in
Section 3.
When the RSA private key owner wishes to limit the use of the public Conforming implementations MUST specify and process the algorithms
key exclusively to RSASSA-PSS, the AlgorithmIdentifier for RSASSA-PSS explicitly by using the OIDs specified in Section 3 when encoding
defined in Section 3 can be used as the algorithm attribute in the ECDSA with SHAKE public keys in CMS messages.
OriginatorPublicKey sequence. The identifier parameters, as
explained in Section 3, MUST be absent. The RSASSA-PSS algorithm The identifier parameters, as explained in Section 3, MUST be absent.
functions and output lengths are the same as defined in
Section 4.2.1.
4.4. Message Authentication Codes 4.4. Message Authentication Codes
KMAC message authentication code (KMAC) is specified in [SP800-185]. KMAC message authentication code (KMAC) is specified in [SP800-185].
In CMS, KMAC algorithm identifiers are located in the In CMS, KMAC algorithm identifiers are located in the
AuthenticatedData macAlgorithm field. The KMAC values are located in AuthenticatedData macAlgorithm field. The KMAC values are located in
the AuthenticatedData mac field. the AuthenticatedData mac field.
When the id-KmacWithSHAKE128 or id-KmacWithSHAKE256 algorithm When the id-KmacWithSHAKE128 or id-KmacWithSHAKE256 algorithm
identifier is used as the MAC algorithm identifier, the parameters identifier is used as the MAC algorithm identifier, the parameters
skipping to change at page 9, line 5 skipping to change at page 9, line 25
an empty string, and L, the integer representing the requested output an empty string, and L, the integer representing the requested output
length in bits, is 256 or 512 for KmacWithSHAKE128 or length in bits, is 256 or 512 for KmacWithSHAKE128 or
KmacWithSHAKE256 respectively in this specification. KmacWithSHAKE256 respectively in this specification.
5. IANA Considerations 5. IANA Considerations
One object identifier for the ASN.1 module in Appendix A was assigned One object identifier for the ASN.1 module in Appendix A was 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) registry: (1.2.840.113549.1.9.16.0) registry:
CMSAlgsForSHAKE-2018 { { iso(1) member-body(2) us(840) CMSAlgsForSHAKE-2019 { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-shakes(TBD) } id-mod-cms-shakes-2019(TBD) }
6. Security Considerations 6. Security Considerations
The SHAKEs are deterministic functions. Like any other deterministic The SHAKEs are deterministic functions. Like any other deterministic
function, executing each function with the same input multiple times function, executing each function with the same input multiple times
will produce the same output. Therefore, users should not expect will produce the same output. Therefore, users should not expect
unrelated outputs (with the same or different output lengths) from unrelated outputs (with the same or different output lengths) from
excuting a SHAKE function with the same input multiple times. The excuting a SHAKE function with the same input multiple times. The
shorter one of any 2 outputs produced from a SHAKE with the same shorter one of any 2 outputs produced from a SHAKE with the same
input is a prefix of the longer one. It is a similar situation as input is a prefix of the longer one. It is a similar situation as
truncating a 512-bit output of SHA-512 by taking its 256 left-most truncating a 512-bit output of SHA-512 by taking its 256 left-most
bits. These 256 left-most bits are a prefix of the 512-bit output. bits. These 256 left-most bits are a prefix of the 512-bit output.
Implementations must protect the signer's private key. Compromise of
the signer's private key permits masquerade.
When more than two parties share the same message-authentication key, When more than two parties share the same message-authentication key,
data origin authentication is not provided. Any party that knows the data origin authentication is not provided. Any party that knows the
message-authentication key can compute a valid MAC, therefore the message-authentication key can compute a valid MAC, therefore the
content could originate from any one of the parties. content could originate from any one of the parties.
Implementers should be aware that cryptographic algorithms may become When using ECDSA with SHAKEs, the ECDSA curve order SHOULD be chosen
weaker with time. As new cryptanalysis techniques are developed and in line with the SHAKE output length. NIST has defined appropriate
computing power increases, the work factor or time required to break use of the hash functions in terms of the algorithm strengths and
a particular cryptographic algorithm may decrease. Therefore, expected time frames for secure use in Special Publications (SPs)
cryptographic algorithm implementations should be modular allowing [SP800-78-4] and [SP800-107]. These documents can be used as guides
new algorithms to be readily inserted. That is, implementers should to choose appropriate key sizes for various security scenarios. In
be prepared to regularly update the set of algorithms in their the context of this document id-ecdsa-with-shake128 is RECOMMENDED
implementations. for curves with group order of 256-bits. id-ecdsa-with-shake256 is
RECOMMENDED for curves with group order of 384-bits or more.
7. Acknowledgements 7. Acknowledgements
This document is based on Russ Housley's draft This document is based on Russ Housley's draft
[I-D.housley-lamps-cms-sha3-hash]. It replaces SHA3 hash functions [I-D.housley-lamps-cms-sha3-hash]. It replaces SHA3 hash functions
by SHAKE128 and SHAKE256 as the LAMPS WG agreed. by SHAKE128 and SHAKE256 as the LAMPS WG agreed.
The authors would like to thank Russ Housley for his guidance and The authors would like to thank Russ Housley for his guidance and
very valuable contributions with the ASN.1 module. very valuable contributions with the ASN.1 module. Valuable feedback
was also provided by Eric Rescorla.
8. References 8. References
8.1. Normative References 8.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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate the Internet X.509 Public Key Infrastructure Certificate
skipping to change at page 11, line 49 skipping to change at page 12, line 15
[SEC1] Standards for Efficient Cryptography Group, "SEC 1: [SEC1] Standards for Efficient Cryptography Group, "SEC 1:
Elliptic Curve Cryptography", May 2009, Elliptic Curve Cryptography", May 2009,
<http://www.secg.org/sec1-v2.pdf>. <http://www.secg.org/sec1-v2.pdf>.
[shake-nist-oids] [shake-nist-oids]
National Institute of Standards and Technology, "Computer National Institute of Standards and Technology, "Computer
Security Objects Register", October 2017, Security Objects Register", October 2017,
<https://csrc.nist.gov/Projects/Computer-Security-Objects- <https://csrc.nist.gov/Projects/Computer-Security-Objects-
Register/Algorithm-Registration>. Register/Algorithm-Registration>.
[SP800-107]
National Institute of Standards and Technology (NIST),
"SP800-107: Recommendation for Applications Using Approved
Hash Algorithms", May 2014,
<https://csrc.nist.gov/csrc/media/publications/sp/800-107/
rev-1/final/documents/draft_revised_sp800-107.pdf>.
[SP800-78-4]
National Institute of Standards and Technology (NIST),
"SP800-78-4: Cryptographic Algorithms and Key Sizes for
Personal Identity Verification", May 2014,
<https://csrc.nist.gov/csrc/media/publications/sp/800-
78/4/final/documents/sp800_78-4_revised_draft.pdf>.
[X9.62] American National Standard for Financial Services (ANSI), [X9.62] American National Standard for Financial Services (ANSI),
"X9.62-2005 Public Key Cryptography for the Financial "X9.62-2005 Public Key Cryptography for the Financial
Services Industry: The Elliptic Curve Digital Signature Services Industry: The Elliptic Curve Digital Signature
Standard (ECDSA)", November 2005. Standard (ECDSA)", November 2005.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
This appendix includes the ASN.1 modules for SHAKEs in CMS. This This appendix includes the ASN.1 modules for SHAKEs in CMS. This
module includes some ASN.1 from other standards for reference. module includes some ASN.1 from other standards for reference.
CMSAlgsForSHAKE-2018 { iso(1) member-body(2) us(840) CMSAlgsForSHAKE-2019 { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-shakes(TBD) } id-mod-cms-shakes-2019(TBD) }
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS ALL; -- EXPORTS ALL;
IMPORTS IMPORTS
DIGEST-ALGORITHM, MAC-ALGORITHM, SMIME-CAPS DIGEST-ALGORITHM, MAC-ALGORITHM, SMIME-CAPS
skipping to change at page 13, line 40 skipping to change at page 14, line 21
-- --
id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD }
id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD }
-- When the id-RSASSA-PSS-* algorithm identifiers are used -- When the id-RSASSA-PSS-* algorithm identifiers are used
-- for a public key or signature in CMS, the AlgorithmIdentifier -- for a public key or signature in CMS, the AlgorithmIdentifier
-- parameters field MUST be absent. The message digest algorithm -- parameters field MUST be absent. The message digest algorithm
-- used in RSASSA-PSS MUST be SHAKE128 or SHAKE256 with a 32 or -- used in RSASSA-PSS MUST be SHAKE128 or SHAKE256 with a 32 or
-- 64 byte outout length respectively. The mask generating -- 64 byte outout length respectively. The mask generating
-- function MUST be SHAKE128 or SHAKE256 with an output length -- function MUST be SHAKE128 or SHAKE256 with an output length
-- of (n - 264)/8 or (n - 520)/8 bytes respectively, where n -- of (n - 264) or (n - 520) bits respectively, where n
-- is the RSA modulus in bits. The RSASSA-PSS saltLength MUST -- is the RSA modulus in bits. The RSASSA-PSS saltLength MUST
-- be 32 or 64 bytes respectively. In both cases, the RSA -- be 32 or 64 bytes respectively. The trailerField MUST be 1,
-- public key, MUST be encoded using the RSAPublicKey type. -- which represents the trailer field with hexadecimal value
-- 0xBC. Regardless of id-RSASSA-PSS-* or rsaEncryption being
-- used as the AlgorithmIdentifier of the OriginatorPublicKey,
-- the RSA public key MUST be encoded using the RSAPublicKey
-- type.
-- From RFC4055, for reference. -- From RFC4055, for reference.
-- RSAPublicKey ::= SEQUENCE { -- RSAPublicKey ::= SEQUENCE {
-- modulus INTEGER, -- -- n -- modulus INTEGER, -- -- n
-- publicExponent INTEGER } -- -- e -- publicExponent INTEGER } -- -- e
id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) country(16) us(840) organization(1)
gov(101) csor(3) nistAlgorithm(4) gov(101) csor(3) nistAlgorithm(4)
sigAlgs(3) TBD } sigAlgs(3) TBD }
id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) country(16) us(840) organization(1)
gov(101) csor(3) nistAlgorithm(4) gov(101) csor(3) nistAlgorithm(4)
sigAlgs(3) TBD } sigAlgs(3) TBD }
-- When the id-ecdsa-with-shake* algorithm identifiers are -- When the id-ecdsa-with-shake* algorithm identifiers are
-- used in CMS, the AlgorithmIdentifier parameters field -- used in CMS, the AlgorithmIdentifier parameters field
-- MUST be absent and the signature algorithm should -- MUST be absent and the signature algorithm should be
-- Deterministric ECDSA [RFC6979]. The message digest MUST -- deterministric ECDSA [RFC6979]. The message digest MUST
-- be SHAKE128 or SHAKE256 with a 32 or 64 byte outout -- be SHAKE128 or SHAKE256 with a 32 or 64 byte outout
-- length respectively. In both cases, the ECDSA public key, -- length respectively. In both cases, the ECDSA public key,
-- MUST be encoded using the id-ecPublicKey type. -- MUST be encoded using the id-ecPublicKey type.
-- From RFC5480, for reference. -- From RFC5480, for reference.
-- id-ecPublicKey OBJECT IDENTIFIER ::= { -- id-ecPublicKey OBJECT IDENTIFIER ::= {
-- iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } -- iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
-- The id-ecPublicKey parameters must be absent or present -- The id-ecPublicKey parameters must be absent or present
-- and are defined as -- and are defined as
-- ECParameters ::= CHOICE { -- ECParameters ::= CHOICE {
-- namedCurve OBJECT IDENTIFIER -- namedCurve OBJECT IDENTIFIER
skipping to change at page 15, line 40 skipping to change at page 16, line 25
hashAlgs(2) 20 } hashAlgs(2) 20 }
KMACwithSHAKE256-params ::= SEQUENCE { KMACwithSHAKE256-params ::= SEQUENCE {
kMACOutputLength INTEGER DEFAULT 512, -- Output length in bits kMACOutputLength INTEGER DEFAULT 512, -- Output length in bits
customizationString OCTET STRING DEFAULT ''H customizationString OCTET STRING DEFAULT ''H
} }
END END
Authors' Addresses Authors' Addresses
Panos Kampanakis
Cisco Systems
Email: pkampana@cisco.com
Quynh Dang Quynh Dang
NIST NIST
100 Bureau Drive 100 Bureau Drive
Gaithersburg, MD 20899 Gaithersburg, MD 20899
Email: quynh.Dang@nist.gov Email: quynh.Dang@nist.gov
Panos Kampanakis
Cisco Systems
Email: pkampana@cisco.com
 End of changes. 35 change blocks. 
83 lines changed or deleted 120 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/