]>
Use of the SHA3 Oneway Hash Functions in the Cryptographic Message Syntax (CMS)
Vigil Security, LLC
Herndon
VA
United States of America
housley@vigilsec.com
Security
InternetDraft
This document describes the conventions for using the oneway hash functions
in the SHA3 family with the Cryptographic Message Syntax (CMS). The SHA3
family can be used as a message digest algorithm, as part of a signature
algorithm, as part of a message authentication code, or part of a key
derivation function.
Introduction
The Cryptographic Message Syntax (CMS) is used to digitally sign,
digest, authenticate, or encrypt arbitrary message contents. This
specification describes the use of the four oneway hash functions in the
SHA3 family (SHA3224, SHA3256, SHA3384, and SHA3512) with the
CMS. In addition, this specification describes the use of these four
oneway hash functions with the RSASSA PKCS#1 version 1.5 signature
algorithm and the Elliptic Curve Digital Signature Algorithm
(ECDSA) with the CMS signeddata content type.
This document should not be confused with RFC 8702 , which defines
conventions for using the the SHAKE family of SHA3based extensible output
functions with the CMS.
ASN.1
CMS values are generated using ASN.1 , using the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER) .
Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they
appear in all capitals, as shown here.
Message Digest Algorithms
Oneway hash functions are also referred to as message digest algorithms.
This section specifies the conventions employed by CMS implementations
that support SHA3224, SHA3256, SHA3384, and SHA3512 .
Digest algorithm identifiers are located in the SignedData digestAlgorithms
field, the SignerInfo digestAlgorithm field, the DigestedData digestAlgorithm
field, and the AuthenticatedData digestAlgorithm field.
Digest values are located in the DigestedData digest field and the Message
Digest authenticated attribute. In addition, digest values are input to
signature algorithms.
SHA3224, SHA3256, SHA3384, and SHA3512 produce output values with
224, 256, 384, and 512 bits, respectively. The object identifiers for
these four oneway hash functions are as follows:
When using the idsha3224, idsha3s256, idsha3384, or idsha3512
algorithm identifiers, the parameters field MUST be absent; not NULL
but absent.
Signature Algorithms
This section specifies the conventions employed by CMS implementations
that support the four SHA3 oneway hash functions with the RSASSA PKCS#1
version 1.5 signature algorithm and the Elliptic Curve Digital
Signature Algorithm (ECDSA) with the CMS signeddata content type.
Signature algorithm identifiers are located in the SignerInfo
signatureAlgorithm field of SignedData. Also, signature algorithm
identifiers are located in the SignerInfo signatureAlgorithm field
of countersignature attributes.
Signature values are located in the SignerInfo signature field of
SignedData. Also, signature values are located in the SignerInfo
signature field of countersignature attributes.
RSASSA PKCS#1 v1.5 with SHA3
The RSASSA PKCS#1 v1.5 is defined in . When RSASSA PKCS#1 v1.5 is
used in conjunction with one of the SHA3 oneway hash functions, the
object identifiers are:
The algorithm identifier for RSASSA PKCS#1 v1.5 subject public keys
in certificates is specified in , and it is repeated here for
convenience:
When the rsaEncryption, idrsassapkcs1v15withsha3224,
idrsassapkcs1v15withsha3256,
idrsassapkcs1v15withsha3384, and
idrsassapkcs1v15withsha3512 algorithm identifier is used,
AlgorithmIdentifier parameters field MUST contain NULL.
When the rsaEncryption algorithm identifier is used, the RSA public key,
which is composed of a modulus and a public exponent, MUST be encoded
using the RSAPublicKey type as specified in . The output of
this encoding is carried in the certificate subject public key. The
definition of RSAPublicKey is repeated here for convenience:
When signing, the RSASSA PKCS#1 v1.5 signature algorithm generates a
single value, and that value is used directly as the signature value.
ECDSA with SHA3
The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
. When ECDSA is used in conjunction with one of the SHA3
oneway hash functions, the object identifiers are:
When using the idecdsawithsha3224, idecdsawithsha3256,
idecdsawithsha3384, and idecdsawithsha3512 algorithm identifiers,
the parameters field MUST be absent; not NULL but absent.
The conventions for ECDSA public keys is as specified in . The
ECParameters associated with the ECDSA public key in the signers
certificate SHALL apply to the verification of the signature.
When signing, the ECDSA algorithm generates two values. These values
are commonly referred to as r and s. To easily transfer these two
values as one signature, they MUST be ASN.1 encoded using the
ECDSASigValue defined in and repeated here for
convenience:
Message Authentication Codes using HMAC and SHA3
This section specifies the conventions employed by CMS implementations
that support the HMAC with SHA3 message authentication code (MAC).
MAC algorithm identifiers are located in the AuthenticatedData
macAlgorithm field.
MAC values are located in the AuthenticatedData mac field.
When HMAC is used in conjunction with one of the SHA3
oneway hash functions, the object identifiers are:
When the idhmacWithSHA3224, idhmacWithSHA3256,
idhmacWithSHA3384, and idhmacWithSHA3512 algorithm
identifier is used, the parameters field MUST be absent;
not NULL but absent.
Key Derivation Functions
The CMS KEMRecipientInfo structure is one place where
algorithm identifiers for keyderivation functions are needed.
HKDF with SHA3
This section assigns four algorithm identifiers that can be employed by CMS
implementations that support the HMACbased ExtractandExpand Key Derivation
Function (HKDF) with the SHA3 family of hash functions.
When HKDF is used in conjunction with one of the SHA3
oneway hash functions, the object identifiers are:
When idalghkdfwithsha3224, idalghkdfwithsha3256,
idalghkdfwithsha3384, or idalghkdfwithsha3512 is used in
an algorithm identifier, the parameters field MUST be absent;
not NULL but absent.
KMAC128KDF and KMAC256KDF
This section specifies the conventions employed by CMS implementations
that employ either the KMAC128 or KMAC256 as a key derivation function as
defined in Section 4.4 of .
KMAC128 and KMAC256 are specified in . The use of KMAC128
and KMAC256 as a key derivation function are defined as:

KMAC128KDF is KMAC128(K, X, L, S).

KMAC256KDF is KMAC256(K, X, L, S).
The parameters to the KMAC128 and KMAC256 functions are:

 K

the input keyderivation key. The length of K MUST be less than 2^2040.

 X

the context, which contains the ASN.1 DER encoding of CMSORIforKEMOtherInfo when the KDF is used with .

 L

the output length, in bits. L MUST be greater than or equal to 0, and L MUST be less than 2^2040.

 S

the optional customization label, such as "KDF" (0x4B4446). The length of S MUST be less than 2^2040.
The K parameter is known to all authorized parties; it is often the output
of a KEM Decap() operation. The X parameter is assembled from data that
is transmitted by the originator. The L parameter is determined by the
size of the output keying material. The S parameter is optional, and if
it is provided by the originator, it is passed in the parameters field of
the KDF algorithm identifier.
When KMAC128KDF or KMAC256KDF is used, the object identifiers are:
When the idkmac128 or idkmac256 is used as part of an algorithm identifier, the
parameters field MUST be absent when there is no customization label S. If any
value is provided for S, then the parameters field MUST be present and
contain the value of S, encoded as Customization.
KDF2 and KDF3 with SHA3
This section specifies the conventions employed by CMS implementations
that employ either the KDF2 or KDF3 functions defined in .
The CMS KEMRecipientInfo structure is one
place where algorithm identifiers for keyderivation functions are needed.
The keyderivation function algorithm identifier is an object identifier
and optional parameters. When KDF2 and KDF3 are used, they are identified by
the idkdfkdf2 and idkdfkdf3 object identifiers, respectively. The
keyderivation function algorithm identifier parameters carry a message
digest algorithm identifier, which indicates the hash function that
is being employed. To support SHA3, the keyderivation function
algorithm identifier parameters contain an algorithm identifier from
.
Security Considerations
Implementations must protect the signer's private key. Compromise of the
signer's private key permits masquerade.
Implementations must protect the keyderivation key. Compromise of the
keyderivation key permits others to derive the derived keying material,
which would result in loss of confidentiality, integrity, or authentication,
depending on the use of the derived keying material.
When more than two parties share the same messageauthentication key,
data origin authentication is not assured. Any party that knows the
messageauthentication key can compute a valid MAC, therefore the content
could originate from any one of the parties.
Implementations must randomly generate messageauthentication keys and
onetime values, such as the k value when generating a ECDSA signature.
In addition, the generation of public/private key pairs relies on a
random numbers. The use of inadequate pseudorandom number generators
(PRNGs) to generate cryptographic values can result in little or no
security. Instead of brute force searching the whole key space, an
attacker may find it much easier to reproduce the PRNG environment that
produced the keys, and then search the resulting small set of
possibilities. The generation of quality random numbers is
difficult. RFC 4086 offers important guidance in this area,
and Appendix 3 of FIPS Pub 1864 provides some PRNG techniques.
Implementers should be aware that cryptographic algorithms become weaker
with time. As new cryptanalysis techniques are developed and computing
performance improves, the work factor to break a particular cryptographic
algorithm will reduce. Therefore, cryptographic algorithm
implementations should be modular allowing new algorithms to be readily
inserted. That is, implementers should be prepared to regularly update
the set of algorithms in their implementations.
IANA Considerations
IANA is asked to assign one object identifier for the ASN.1 module in
in the "SMI Security for S/MIME Module Identifiers (1.2.840.113549.1.9.16.0)"
registry :
IANA is asked to assign four object identifiers for the HKDF using SHA3 algorithm
identifiers in the "SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)"
registry :
Acknowledgements
Thanks to
Daniel Van Geest and
Sean Turner
for their careful review and thoughtful comments.
Thanks to Sara Kerman, Quynh Dang, and David Cooper
for getting the object identifiers assigned for KMAC128 and KMAC256.
References
Normative References
Public Key Cryptography for the Financial Services Industry  Key Establishment Using Integer Factorization Cryptography
American National Standards Institute
Recommendation for key derivation using pseudorandom functions
National Institute of Standards and Technology
SHA3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash
National Institute of Standards and Technology
HMAC: KeyedHashing for Message Authentication
This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind
Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDSTRACK]
Cryptographic Message Syntax (CMS)
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDSTRACK]
Elliptic Curve Cryptography Subject Public Key Information
This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDSTRACK]
HMACbased ExtractandExpand Key Derivation Function (HKDF)
This document specifies a simple Hashed Message Authentication Code (HMAC)based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.
New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)
The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bitsonthewire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.
PKCS #1: RSA Cryptography Specifications Version 2.2
This document provides recommendations for the implementation of publickey cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.
This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' PublicKey Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.
This document also obsoletes RFC 3447.
SHA3 Standard: PermutationBased Hash and ExtendableOutput Functions
National Institute of Standards and Technology
Digital Signature Standard (DSS)
National Institute of Standards and Technology
Information technology  Abstract Syntax Notation One (ASN.1): Specification of basic notation
ITUT
Information technology  ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
ITUT
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
Informative References
SMI Security for for S/MIME Algorithms (1.2.840.113549.1.9.16.3)
IANA
n.d.
SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)
IANA
n.d.
Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)
Vigil Security, LLC
Entrust
DigiCert, Inc.
The Cryptographic Message Syntax (CMS) supports key transport and key
agreement algorithms. In recent years, cryptographers have been
specifying Key Encapsulation Mechanism (KEM) algorithms, including
quantumsecure KEM algorithms. This document defines conventions for
the use of KEM algorithms by the originator and recipients to encrypt
and decrypt CMS content. This document updates RFC 5652.
Randomness Requirements for Security
Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudorandom processes to generate secret quantities can result in pseudosecurity. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.
Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudorandom number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Use of the SHAKE OneWay Hash Functions in the Cryptographic Message Syntax (CMS)
This document updates the "Cryptographic Message Syntax (CMS) Algorithms" (RFC 3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as oneway hash functions with the RSA Probabilistic Signature Scheme (RSASSAPSS) and Elliptic Curve Digital Signature Algorithm (ECDSA). The conventions for the associated signer public keys in CMS are also described.
Appendix. ASN.1 Module
This section contains the ASN.1 module for the algorithm identifiers using SHA3
family of hash functions . This module imports types from other ASN.1
modules that are defined in .