Vigil Security, LLC

Herndon VA United States of America housley@vigilsec.com

SEC lamps example This document describes the conventions for using the one-way 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 as part of a Key Derivation Function (KDF).

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
  • .  ASN.1
  • .  Terminology
• .  Message Digest Algorithms
• .  Signature Algorithms
  • .  RSASSA PKCS#1 v1.5 with SHA3
  • .  ECDSA with SHA3
• .  Message Authentication Codes Using HMAC and SHA3
• .  Key Derivation Functions
  • .  HKDF with SHA3
  • .  KMAC128-KDF and KMAC256-KDF
  • .  KDF2 and KDF3 with SHA3
• .  Security Considerations
• .  IANA Considerations
• .  References
  • .  Normative References
  • .  Informative References
• .  ASN.1 Module
• Acknowledgements
• Author's Address

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. This document should not be confused with , which defines conventions for using the SHAKE family of SHA3-based extensible output functions with the CMS.

ASN.1 CMS values are generated with 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: hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 } id-sha3-224 OBJECT IDENTIFIER ::= { hashAlgs 7 } id-sha3-256 OBJECT IDENTIFIER ::= { hashAlgs 8 } id-sha3-384 OBJECT IDENTIFIER ::= { hashAlgs 9 } id-sha3-512 OBJECT IDENTIFIER ::= { hashAlgs 10 } 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 v1.5 signature algorithm and the 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: OID ::= OBJECT IDENTIFIER sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 3 } id-rsassa-pkcs1-v1-5-with-sha3-224 OID ::= { sigAlgs 13 } id-rsassa-pkcs1-v1-5-with-sha3-256 OID ::= { sigAlgs 14 } id-rsassa-pkcs1-v1-5-with-sha3-384 OID ::= { sigAlgs 15 } id-rsassa-pkcs1-v1-5-with-sha3-512 OID ::= { sigAlgs 16 } The algorithm identifier for RSASSA PKCS#1 v1.5 subject public keys in certificates is specified in , and it is repeated here for convenience: rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 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 identifiers are used, the 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: RSAPublicKey ::= SEQUENCE { modulus INTEGER, -- n publicExponent INTEGER } -- e When signing, the RSASSA PKCS#1 v1.5 signature algorithm generates a single value. That value is used directly as the signature value.

ECDSA with SHA3 The ECDSA is defined in . When the ECDSA is used in conjunction with one of the SHA3 one-way hash functions, the object identifiers are: sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 3 } id-ecdsa-with-sha3-224 OBJECT IDENTIFIER ::= { sigAlgs 9 } id-ecdsa-with-sha3-256 OBJECT IDENTIFIER ::= { sigAlgs 10 } id-ecdsa-with-sha3-384 OBJECT IDENTIFIER ::= { sigAlgs 11 } id-ecdsa-with-sha3-512 OBJECT IDENTIFIER ::= { sigAlgs 12 } When the id-sha3-224, id-sha3-s256, id-sha3-384, or id-sha3-512 algorithm identifier is used, the parameters field MUST be absent, not NULL but absent. When the id-ecdsa-with-sha3-224, id-ecdsa-with-sha3-256, id- ecdsa-with-sha3-384, and id-ecdsa-with-sha3-512 algorithm identifiers are used, the parameters field MUST be absent, not NULL but absent. The conventions for ECDSA public keys are 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 , which is repeated here for convenience: ECDSA-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER }

Message Authentication Codes Using HMAC and SHA3 This section specifies the conventions employed by CMS implementations that support the Hashed Message Authentication Code (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: hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 } id-hmacWithSHA3-224 OBJECT IDENTIFIER ::= { hashAlgs 13 } id-hmacWithSHA3-256 OBJECT IDENTIFIER ::= { hashAlgs 14 } id-hmacWithSHA3-384 OBJECT IDENTIFIER ::= { hashAlgs 15 } id-hmacWithSHA3-512 OBJECT IDENTIFIER ::= { hashAlgs 16 } When the id-hmacWithSHA3-224, id-hmacWithSHA3-256, id-hmacWithSHA3-384, and id-hmacWithSHA3-512 algorithm identifiers are 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 key-derivation functions are needed.

HKDF with SHA3 This section assigns four algorithm identifiers that can be employed by CMS implementations that support the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) with the SHA3 family of hash functions. When HKDF is used in conjunction with one of the SHA3 one-way hash functions, the object identifiers are: id-alg OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 3 } id-alg-hkdf-with-sha3-224 OBJECT IDENTIFIER ::= { id-alg 32 } id-alg-hkdf-with-sha3-256 OBJECT IDENTIFIER ::= { id-alg 33 } id-alg-hkdf-with-sha3-384 OBJECT IDENTIFIER ::= { id-alg 34 } id-alg-hkdf-with-sha3-512 OBJECT IDENTIFIER ::= { id-alg 35 } When id-alg-hkdf-with-sha3-224, id-alg-hkdf-with-sha3-256, id-alg-hkdf-with-sha3-384, or id-alg-hkdf-with-sha3-512 is used in an algorithm identifier, the parameters field MUST be absent, not NULL but absent.

KMAC128-KDF and KMAC256-KDF This section specifies the conventions employed by CMS implementations that employ either KMAC128 or KMAC256 as KDFs as defined in Section 4.4 of . KMAC128 and KMAC256 are specified in . The use of KMAC128 and KMAC256 as KDFs are defined as follows: KMAC128-KDF is KMAC128(K, X, L, S). KMAC256-KDF is KMAC256(K, X, L, S). The parameters to the KMAC128 and KMAC256 functions are:

K

The input key-derivation key. The length of K MUST be less than 2²⁰⁴⁰.

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 MUST be less than 2²⁰⁴⁰.

S

The optional customization label, such as "KDF" (0x4B4446). The length of S MUST be less than 2²⁰⁴⁰.

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 KMAC128-KDF or KMAC256-KDF is used, the object identifiers are: hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 } id-kmac128 OBJECT IDENTIFIER ::= { hashAlgs 21 } id-kmac256 OBJECT IDENTIFIER ::= { hashAlgs 22 } When id-kmac128 or id-kmac256 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. Customization ::= OCTET STRING

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 key-derivation functions are needed. The key-derivation function algorithm identifier is an object identifier and optional parameters. When KDF2 and KDF3 are used, they are identified by the id-kdf-kdf2 and id-kdf-kdf3 object identifiers, respectively. The key-derivation function algorithm identifier parameters carry a message digest algorithm identifier, which indicates the hash function that is being employed. To support SHA3, the key-derivation function algorithm identifier parameters contain an algorithm identifier from . x9-44 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) tc68(133) country(16) x9(840) x9Standards(9) x9-44(44) } x9-44-components OBJECT IDENTIFIER ::= { x9-44 components(1) } id-kdf-kdf2 OBJECT IDENTIFIER ::= { x9-44-components kdf2(1) } id-kdf-kdf3 OBJECT IDENTIFIER ::= { x9-44-components kdf3(2) }

Security Considerations Implementations must protect the signer's private key. Compromise of the signer's private key permits masquerade. Implementations must protect the key-derivation key. Compromise of the key-derivation 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 message-authentication key, data origin authentication is not assured. 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 a per-message secret number (called the k value) when generating an 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. 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.

IANA Considerations IANA has assigned 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 : id-mod-sha3-oids-2023 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) mod(0) 78 } IANA has assigned 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 : id-alg-hkdf-with-sha3-224 OBJECT IDENTIFIER ::= { id-alg 32 } id-alg-hkdf-with-sha3-256 OBJECT IDENTIFIER ::= { id-alg 33 } id-alg-hkdf-with-sha3-384 OBJECT IDENTIFIER ::= { id-alg 34 } id-alg-hkdf-with-sha3-512 OBJECT IDENTIFIER ::= { id-alg 35 }

References Normative References American National Standards Institute National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology 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 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. 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 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 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 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. 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 bits-on-the-wire 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. 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. 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. National Institute of Standards and Technology ITU-T ITU-T Informative References IANA IANA 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. 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 one-way hash functions with the RSA Probabilistic Signature Scheme (RSASSA-PSS) and Elliptic Curve Digital Signature Algorithm (ECDSA). The conventions for the associated signer public keys in CMS are also described. 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 quantum-secure 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.

ASN.1 Module This section contains the ASN.1 module for the algorithm identifiers using the SHA3 family of hash functions . This module imports types from other ASN.1 modules that are defined in . SHA3-OIDs-2023 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-sha3-oids-2023(78) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS AlgorithmIdentifier{}, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM, KEY-DERIVATION, MAC-ALGORITHM FROM AlgorithmInformation-2009 -- [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } mda-sha1, pk-rsa, pk-ec, ECDSA-Sig-Value FROM PKIXAlgs-2009 -- [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-algorithms2008-02(56) } mda-sha224, mda-sha256, mda-sha384, mda-sha512 FROM PKIX1-PSS-OAEP-Algorithms-2009 -- [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-rsa-pkalgs-02(54) } ; -- -- Alias -- OID ::= OBJECT IDENTIFIER -- -- Object Identifier Arcs -- nistAlgorithm OID ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) 4 } hashAlgs OID ::= { nistAlgorithm 2 } sigAlgs OID ::= { nistAlgorithm 3 } x9-44 OID ::= { iso(1) identified-organization(3) tc68(133) country(16) x9(840) x9Standards(9) x9-44(44) } x9-44-components OID ::= { x9-44 components(1) } id-alg OID ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 3 } -- -- Message Digest Algorithms -- id-sha3-224 OID ::= { hashAlgs 7 } id-sha3-256 OID ::= { hashAlgs 8 } id-sha3-384 OID ::= { hashAlgs 9 } id-sha3-512 OID ::= { hashAlgs 10 } mda-sha3-224 DIGEST-ALGORITHM ::= { IDENTIFIER id-sha3-224 PARAMS ARE absent } mda-sha3-256 DIGEST-ALGORITHM ::= { IDENTIFIER id-sha3-256 PARAMS ARE absent } mda-sha3-384 DIGEST-ALGORITHM ::= { IDENTIFIER id-sha3-384 PARAMS ARE absent } mda-sha3-512 DIGEST-ALGORITHM ::= { IDENTIFIER id-sha3-512 PARAMS ARE absent } HashAlgorithm ::= AlgorithmIdentifier{ DIGEST-ALGORITHM, { HashAlgorithms } } HashAlgorithms DIGEST-ALGORITHM ::= { mda-sha3-224 | mda-sha3-256 | mda-sha3-384 | mda-sha3-512, ... } -- -- Signature Algorithms -- id-rsassa-pkcs1-v1-5-with-sha3-224 OID ::= { sigAlgs 13 } id-rsassa-pkcs1-v1-5-with-sha3-256 OID ::= { sigAlgs 14 } id-rsassa-pkcs1-v1-5-with-sha3-384 OID ::= { sigAlgs 15 } id-rsassa-pkcs1-v1-5-with-sha3-512 OID ::= { sigAlgs 16 } id-ecdsa-with-sha3-224 OID ::= { sigAlgs 9 } id-ecdsa-with-sha3-256 OID ::= { sigAlgs 10 } id-ecdsa-with-sha3-384 OID ::= { sigAlgs 11 } id-ecdsa-with-sha3-512 OID ::= { sigAlgs 12 } sa-rsaWithSHA3-224 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-rsassa-pkcs1-v1-5-with-sha3-224 PARAMS TYPE NULL ARE required HASHES { mda-sha3-224 } PUBLIC-KEYS { pk-rsa } SMIME-CAPS {IDENTIFIED BY id-rsassa-pkcs1-v1-5-with-sha3-224 } } sa-rsaWithSHA3-256 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-rsassa-pkcs1-v1-5-with-sha3-256 PARAMS TYPE NULL ARE required HASHES { mda-sha3-256 } PUBLIC-KEYS { pk-rsa } SMIME-CAPS {IDENTIFIED BY id-rsassa-pkcs1-v1-5-with-sha3-256 } } sa-rsaWithSHA3-384 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-rsassa-pkcs1-v1-5-with-sha3-384 PARAMS TYPE NULL ARE required HASHES { mda-sha3-384 } PUBLIC-KEYS { pk-rsa } SMIME-CAPS {IDENTIFIED BY id-rsassa-pkcs1-v1-5-with-sha3-384 } } sa-rsaWithSHA3-512 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-rsassa-pkcs1-v1-5-with-sha3-512 PARAMS TYPE NULL ARE required HASHES { mda-sha3-512 } PUBLIC-KEYS { pk-rsa } SMIME-CAPS {IDENTIFIED BY id-rsassa-pkcs1-v1-5-with-sha3-512 } } sa-ecdsaWithSHA3-224 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-ecdsa-with-sha3-224 VALUE ECDSA-Sig-Value PARAMS ARE absent HASHES { mda-sha3-224 } PUBLIC-KEYS { pk-ec } SMIME-CAPS {IDENTIFIED BY id-ecdsa-with-sha3-224 } } sa-ecdsaWithSHA3-256 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-ecdsa-with-sha3-256 VALUE ECDSA-Sig-Value PARAMS ARE absent HASHES { mda-sha3-256 } PUBLIC-KEYS { pk-ec } SMIME-CAPS {IDENTIFIED BY id-ecdsa-with-sha3-256 } } sa-ecdsaWithSHA3-384 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-ecdsa-with-sha3-384 VALUE ECDSA-Sig-Value PARAMS ARE absent HASHES { mda-sha3-384 } PUBLIC-KEYS { pk-ec } SMIME-CAPS {IDENTIFIED BY id-ecdsa-with-sha3-384 } } sa-ecdsaWithSHA3-512 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-ecdsa-with-sha3-512 VALUE ECDSA-Sig-Value PARAMS ARE absent HASHES { mda-sha3-512 } PUBLIC-KEYS { pk-ec } SMIME-CAPS {IDENTIFIED BY id-ecdsa-with-sha3-512 } } SignatureAlg ::= AlgorithmIdentifier{ SIGNATURE-ALGORITHM, { SignatureAlgs } } SignatureAlgs SIGNATURE-ALGORITHM ::= { sa-rsaWithSHA3-224 | sa-rsaWithSHA3-256 | sa-rsaWithSHA3-384 | sa-rsaWithSHA3-512 | sa-ecdsaWithSHA3-224 | sa-ecdsaWithSHA3-256 | sa-ecdsaWithSHA3-384 | sa-ecdsaWithSHA3-512, ... } -- -- Message Authentication Codes -- id-hmacWithSHA3-224 OID ::= { hashAlgs 13 } id-hmacWithSHA3-256 OID ::= { hashAlgs 14 } id-hmacWithSHA3-384 OID ::= { hashAlgs 15 } id-hmacWithSHA3-512 OID ::= { hashAlgs 16 } maca-hmacWithSHA3-224 MAC-ALGORITHM ::= { IDENTIFIER id-hmacWithSHA3-224 PARAMS ARE absent IS-KEYED-MAC TRUE SMIME-CAPS {IDENTIFIED BY id-hmacWithSHA3-224 } } maca-hmacWithSHA3-256 MAC-ALGORITHM ::= { IDENTIFIER id-hmacWithSHA3-256 PARAMS ARE absent IS-KEYED-MAC TRUE SMIME-CAPS {IDENTIFIED BY id-hmacWithSHA3-256 } } maca-hmacWithSHA3-384 MAC-ALGORITHM ::= { IDENTIFIER id-hmacWithSHA3-384 PARAMS ARE absent IS-KEYED-MAC TRUE SMIME-CAPS {IDENTIFIED BY id-hmacWithSHA3-384 } } maca-hmacWithSHA3-512 MAC-ALGORITHM ::= { IDENTIFIER id-hmacWithSHA3-512 PARAMS ARE absent IS-KEYED-MAC TRUE SMIME-CAPS {IDENTIFIED BY id-hmacWithSHA3-512 } } MACAlgorithm ::= AlgorithmIdentifier{ MAC-ALGORITHM, { MACAlgorithms } } MACAlgorithms MAC-ALGORITHM ::= { maca-hmacWithSHA3-224 | maca-hmacWithSHA3-256 | maca-hmacWithSHA3-384 | maca-hmacWithSHA3-512, ... } -- -- Key Derivation Algorithms -- id-alg-hkdf-with-sha3-224 OID ::= { id-alg 32 } id-alg-hkdf-with-sha3-256 OID ::= { id-alg 33 } id-alg-hkdf-with-sha3-384 OID ::= { id-alg 34 } id-alg-hkdf-with-sha3-512 OID ::= { id-alg 35 } id-kmac128 OID ::= { hashAlgs 21 } id-kmac256 OID ::= { hashAlgs 22 } id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) } id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) } kda-hkdf-with-sha3-224 KEY-DERIVATION ::= { IDENTIFIER id-alg-hkdf-with-sha3-224 PARAMS ARE absent -- No S/MIME caps defined -- } kda-hkdf-with-sha3-256 KEY-DERIVATION ::= { IDENTIFIER id-alg-hkdf-with-sha3-256 PARAMS ARE absent -- No S/MIME caps defined -- } kda-hkdf-with-sha3-384 KEY-DERIVATION ::= { IDENTIFIER id-alg-hkdf-with-sha3-384 PARAMS ARE absent -- No S/MIME caps defined -- } kda-hkdf-with-sha3-512 KEY-DERIVATION ::= { IDENTIFIER id-alg-hkdf-with-sha3-512 PARAMS ARE absent -- No S/MIME caps defined -- } kda-kmac128 KEY-DERIVATION ::= { IDENTIFIER id-kmac128 PARAMS TYPE Customization ARE optional -- PARAMS are absent when Customization is ''H -- -- No S/MIME caps defined -- } kda-kmac256 KEY-DERIVATION ::= { IDENTIFIER id-kmac256 PARAMS TYPE Customization ARE optional -- PARAMS are absent when Customization is ''H -- -- No S/MIME caps defined -- } kda-kdf2 KEY-DERIVATION ::= { IDENTIFIER id-kdf-kdf2 PARAMS TYPE KDF2-HashFunction ARE required -- No S/MIME caps defined -- } kda-kdf3 KEY-DERIVATION ::= { IDENTIFIER id-kdf-kdf3 PARAMS TYPE KDF3-HashFunction ARE required -- No S/MIME caps defined -- } Customization ::= OCTET STRING KDF2-HashFunction ::= AlgorithmIdentifier { DIGEST-ALGORITHM, { KDF2-HashFunctions } } KDF2-HashFunctions DIGEST-ALGORITHM ::= { X9-HashFunctions, ... } KDF3-HashFunction ::= AlgorithmIdentifier { DIGEST-ALGORITHM, { KDF3-HashFunctions } } KDF3-HashFunctions DIGEST-ALGORITHM ::= { X9-HashFunctions, ... } X9-HashFunctions DIGEST-ALGORITHM ::= { mda-sha1 | mda-sha224 | mda-sha256 | mda-sha384 | mda-sha512 | mda-sha3-224 | mda-sha3-256 | mda-sha3-384 | mda-sha3-512, ... } KeyDerivationFunction ::= AlgorithmIdentifier{ KEY-DERIVATION, { KeyDevAlgs } } KeyDevAlgs KEY-DERIVATION ::= { kda-hkdf-with-sha3-224 | kda-hkdf-with-sha3-256 | kda-hkdf-with-sha3-384 | kda-hkdf-with-sha3-512 | kda-kmac128 | kda-kmac256 | kda-kdf2 | kda-kdf3, ... } END

Acknowledgements Thanks to and for their careful review and thoughtful comments. Thanks to , , and for getting the object identifiers assigned for KMAC128 and KMAC256.

Author's Address Vigil Security, LLC

Herndon VA United States of America housley@vigilsec.com