]> Vigil Security, LLC

Herndon, VA US housley@vigilsec.com

Security Internet-Draft This document describes the conventions for using the four one-way hash functions in the SHA3 family with the Cryptographic Message Syntax (CMS).

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 one-way hash functions in the SHA3 family (SHA3-224, SHA3-256, SHA3-384, and SHA3-512) with the CMS. In addition, this specification describes the use of these four one-way hash functions with the RSASSA PKCS#1 version 1.5 signature algorithm and the Elliptic Curve Digital Signature Algorithm (ECDSA) with the CMS signed-data content type.

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 One-way hash functions are also referred to as message digest algorithms.
This section specifies the conventions employed by CMS implementations that support SHA3-224, SHA3-256, SHA3-384, and SHA3-512 . 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. SHA3-224, SHA3-256, SHA3-384, and SHA3-512 produce output values with 224, 256, 384, and 512 bits, respectively. The object identifiers for these four one-way hash functions are as follows: When using the id-sha3-224, id-sha3-s256, id-sha3-384, or id-sha3-512 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 one-way hash functions with the RSASSA PKCS#1 version 1.5 signature algorithm and the Elliptic Curve Digital Signature Algorithm (ECDSA) with the CMS signed-data 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 one-way 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, id-rsassa-pkcs1-v1_5-with-sha3-224, id-rsassa-pkcs1-v1_5-with-sha3-256, id-rsassa-pkcs1-v1_5-with-sha3-384, and id-rsassa-pkcs1-v1_5-with-sha3-512 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 one-way hash functions, the object identifiers are: When using the id-ecdsa-with-sha3-224, id-ecdsa-with-sha3-256, id-ecdsa-with-sha3-384, and id-ecdsa-with-sha3-512 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 ECDSA-Sig-Value defined in and repeated here for convenience:

Message Authentication Codes 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 one-way hash functions, the object identifiers are: When the id-hmacWithSHA3-224, id-hmacWithSHA3-256, id-hmacWithSHA3-384, and id-hmacWithSHA3-512 algorithm identifier is used, the parameters field MUST be absent; not NULL but absent.

Security Considerations 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, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid MAC, therefore the content could originate from any one of the parties. Implementations must randomly generate message-authentication keys and one-time 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 pseudo-random number generators (PRNGs) to generate cryptographic such values 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. RFC 4086 offers important guidance in this area, and Appendix 3 of FIPS Pub 186-4 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.

References Normative References 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, SHA-1, 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 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. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] 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. [STANDARDS-TRACK] This document provides recommendations for the implementation of public-key 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' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. National Institute of Standards and Technology National Institute of Standards and Technology ITU-T ITU-T 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. 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 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 pseudo-random processes to generate secret quantities can result in pseudo-security. 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 pseudo-random 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.

Appendix. ASN.1 Module TBD