]> CryptoNext Security

daniel.vangeest@cryptonext-security.com

sn3rd

sean@sn3rd.com

Security Limited Additional Mechanisms for PKIX and SMIME CMS FN-DSA Falcon PKIX S/MIME The Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA), as defined by NIST in FIPS 206, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the FN-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier is provided. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA) is a digital signature algorithm standardised by the US National Institute of Standards and Technology (NIST) as part of their post-quantum cryptography standardisation process. It is intended to be secure against both "traditional" cryptographic attacks, as well as attacks utilising a quantum computer. It offers smaller signatures and significantly faster runtimes than SLH-DSA , an alternative post-quantum signature algorithm also standardised by NIST. This document specifies the use of the FN-DSA in the CMS at two security levels: FN-DSA-512 and FN-DSA-1024. See Appendix B of I-D.turner-lamps-fn-dsa-certificates for more information on the security levels and key sizes of FN-DSA. Prior to standardisation, FN-DSA was known as Falcon. FN-DSA and Falcon are not compatible. For each of the FN-DSA parameter sets, an algorithm identifier Object Identifier (OID) has been specified.

Conventions and Definitions 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.

FN-DSA Algorithm Identifiers Many ASN.1 data structure types use the AlgorithmIdentifier type to identify cryptographic algorithms. In the CMS, the AlgorithmIdentifier field is used to identify FN-DSA signatures in the signed-data content type. They may also appear in X.509 certificates used to verify those signatures. The same AlgorithmIdentifier values are used to identify FN-DSA public keys and signature algorithms. I-D.turner-lamps-fn-dsa-certificates describes the use of FN-DSA in X.509 certificates. The AlgorithmIdentifier type is defined as follows: The fields in the AlgorithmIdentifier type have the following meanings:

algorithm:

The algorithm field contains an OID that identifies the cryptographic algorithm in use. The OIDs for FN-DSA are described below.

parameters:

The parameters field contains parameter information for the algorithm identified by the OID in the algorithm field. Each FN-DSA parameter set is identified by its own algorithm OID, so there is no relevant information to include in this field. As such, parameters MUST be omitted when encoding an FN-DSA AlgorithmIdentifier.

The OIDs for FN-DSA are defined in the NIST Computer Security Objects Register , and are reproduced here for convenience.

Signed-Data Conventions

Pure Mode vs Pre-hash Mode specifies that digital signatures for CMS are produced using a digest of the message to be signed and the signer's private key. At the time of publication of that RFC, all signature algorithms supported in the CMS required a message digest to be calculated externally to that algorithm, which would then be supplied to the algorithm implementation when calculating and verifying signatures. Since then, EdDSA , ML-DSA , and SLH-DSA , have also been standardised, and these algorithms support both a "pure" and "pre-hash" mode. In the pre-hash mode, a message digest (the "pre-hash") is calculated separately and supplied to the signature algorithm as described above. In the pure mode, the message to be signed or verified is instead supplied directly to the signature algorithm. When EdDSA , SLH-DSA , and ML-DSA are used with CMS, only the pure mode of those algorithms is specified. This is because in most situations, CMS signatures are computed over a set of signed attributes that contain a hash of the content, rather than being computed over the message content itself. Since signed attributes are typically small, use of pre-hash modes in the CMS would not significantly reduce the size of the data to be signed, and hence offers no benefit. This document follows that convention and does not specify the use of FN-DSA's pre-hash mode ("HashFN-DSA") in the CMS.

Signature Generation and Verification describes the two methods that are used to calculate and verify signatures in the CMS. One method is used when signed attributes are present in the signedAttrs field of the relevant SignerInfo, and another is used when signed attributes are absent. Each method produces a different "message digest" to be supplied to the signature algorithm in question, but because the pure mode of FN-DSA is used, the "message digest" is in fact the entire message. Use of signed attributes is preferred, but the conventions for signed-data without signed attributes is also described below for completeness. When signed attributes are absent, FN-DSA (pure mode) signatures are computed over the content of the signed-data. As described in , the "content" of a signed-data is the value of the encapContentInfo eContent OCTET STRING. The tag and length octets are not included. When signed attributes are included, FN-DSA (pure mode) signatures are computed over the complete DER encoding of the SignedAttrs value contained in the SignerInfo's signedAttrs field. As described in , this encoding includes the tag and length octets, but an EXPLICIT SET OF tag is used rather than the IMPLICIT \[0\] tag that appears in the final message. At a minimum, the signedAttrs field MUST at minimum include a content-type attribute and a message-digest attribute. The message-digest attribute contains a hash of the content of the signed-data, where the content is as described for the absent signed attributes case above. Recalculation of the hash value by the recipient is an important step in signature verification. describes how, when the content of a signed-data is large, performance may be improved by including signed attributes. This is as true for FN-DSA as it is for SLH-DSA, although FN-DSA signature generation and verification is significantly faster than SLH-DSA. FN-DSA has a context string input that can be used to ensure that different signatures are generated for different application contexts. When using FN-DSA as specified in this document, the context string is set to the empty string.

SignerInfo Content When using FN-DSA, the fields of a SignerInfo are used as follows:

digestAlgorithm:

Per , the digestAlgorithm field identifies the message digest algorithm used by the signer, and any associated parameters. Each FN-DSA parameter set ...

: shows appropriate SHA-2 and SHA-3 digest

algorithms for each parameter set.

SHA-512 MUST be supported for use with the variants of FN-DSA in this document. SHA-512 is suitable for all FN-DSA parameter sets and provides an interoperable option for legacy CMS implementations that wish to migrate to use post-quantum cryptography, but that may not support use of SHA-3 derivatives at the CMS layer. However, other hash functions MAY also be supported; in particular, SHAKE256 SHOULD be supported, as this is the digest algorithm used internally in FN-DSA. When SHA-512 is used, the id-sha512 digest algorithm identifier is used and the parameters field MUST be omitted. When SHAKE256 is used, the id-shake256 digest algorithm identifier is used and the parameters field MUST be omitted. SHAKE256 produces 512 bits of output when used as a message digest algorithm in the CMS.

When signing using FN-DSA without including signed attributes, the algorithm specified in the digestAlgorithm field has no meaning, as FN-DSA computes signatures over entire messages rather than externally computed digests. As such, the considerations above and in do not apply. Nonetheless, in this case implementations MUST specify SHA-512 as the digestAlgorithm in order to minimise the likelihood of an interoperability failure. When processing a SignerInfo signed using FN-DSA, if no signed attributes are present, implementations MUST ignore the content of the digestAlgorithm field.

Suitable Digest Algorithms for FN-DSA

Signature Algorithm	Digest Algorithms
FN-DSA-512	SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256
FN-DSA-1024	SHA-512, SHA3-512, SHAKE256

signatureAlgorithm:

The signatureAlgorithm field MUST contain one of the FN-DSA signature algorithm OIDs, and the parameters field MUST be absent. The algorithm OID MUST be one of the following OIDs described in :

Signature algorithm identifier OIDs for FN-DSA

Signature Algorithm	Algorithm Identifier OID
FN-DSA-512	id-fn-dsa-512
FN-DSA-10124	id-fn-dsa-1024

signature:

The signature field contains the signature value resulting from the use of the FN-DSA signature algorithm identified by the signatureAlgorithm field. The FN-DSA (pure mode) signature-generation operation is specified in Section X.X of , and the signature-verification operation is specified in Section X.X of . Note that places further requirements on the successful verification of a signature.

Security Considerations The security considerations in and I-D.turner-lamps-fn-dsa-certificates apply to this specification. Security of the FN-DSA private key is critical. Compromise of the private key will enable an adversary to forge arbitrary signatures. FN-DSA depends on high quality random numbers that are suitable for use in cryptography. The use of inadequate pseudo-random number generators (PRNGs) to generate such values can significantly undermine the security properties offered by a cryptographic algorithm. For instance, an attacker may find it much easier to reproduce the PRNG environment that produced any private keys, searching the resulting small set of possibilities, rather than brute-force searching the whole key space. The generation of random numbers of a sufficient level of quality for use in cryptography is difficult; see Section X.X.X of for some additional information. FN-DSA signature generation uses randomness from two sources: fresh random data generated during signature generation, and precomputed random data included in the signer's private key. Inclusion of both sources of random data can help mitigate against faulty random number generators, side-channel attacks, and fault attacks. Lack of fresh random data during FN-DSA signature generation leads to a differential fault attack . Side channel attacks and fault attacks against FN-DSA are an active area of research XX XX. Future protection against these styles of attack may involve interoperable changes to the implementation of FN-DSA's internal functions. Implementers SHOULD consider implementing such protection measures if it would be beneficial for their particular use cases. To avoid algorithm substitution attacks, the CMSAlgorithmProtection attribute defined in SHOULD be included in signed attributes.

Operational Considerations If FN-DSA signing is implemented in a hardware device such as a hardware security module (HSM) or a portable cryptographic token, implementers might want to avoid sending the full content to the device for performance reasons. By including signed attributes, which necessarily includes the message-digest attribute and the content-type attribute as described in , the much smaller set of signed attributes are sent to the device for signing.

IANA Considerations For the ASN.1 module in , IANA [ is requested/has assigned ] the following object identifier (OID) in the "SMI Security for S/MIME Module Identifier" registry (1.2.840.113549.1.9.16.0): Object Identifier Assignments

Decimal	Description	Reference
TBD	id-mod-fn-dsa-2026	This RFC

References Normative References n.d. 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. 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 describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. [STANDARDS-TRACK] 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), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process. [STANDARDS-TRACK] Informative References ITU-T The Cryptographic Message Syntax (CMS) 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 memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (U.S.) This document specifies the conventions for using the Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS. SLH-DSA is a stateless hash-based signature algorithm. This document specifies the conventions for using the SLH-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined by NIST in FIPS 204, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the ML-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier syntax is provided. National Institute of Standards and Technology (U.S.) AWS AWS sn3rd Cloudflare Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described. Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described.

ASN.1 Module FN-DSA-Module-2026 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-smime(16) id-mod(0) id-mod-fn-dsa-2026(TBD1) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS SIGNATURE-ALGORITHM, SMIME-CAPS FROM AlgorithmInformation-2009 -- in [RFC5911] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } sa-fn-dsa-512, sa-fn-dsa-10124 FROM X509-FN-DSA-2026 -- From [I-D.turner-lamps-fn-dsa-certificates] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-x509-fn-dsa-2024(TBD2) } ; -- -- Expand the signature algorithm set used by CMS [RFC5911] -- SignatureAlgorithmSet SIGNATURE-ALGORITHM ::= { sa-fn-dsa-512 | sa-fn-dsa-1024, ... } SMimeCaps SMIME-CAPS ::= { sa-fn-dsa-512.&smimeCaps | sa-fn-dsa-1024.&smimeCaps, ... } END ]]>

Examples This appendix contains example signed-data encodings. They can be verified using the example public keys and certificates specified in Appendix C of I-D.turner-lamps-fn-dsa-certificates. The following is an example of a signed-data with a single FN-DSA-512 signer, with signed attributes included: The following is an example of a signed-data with a single FN-DSA-1024 signer, with signed attributes included:

Acknowledgments This document was heavily influenced by , , and . Thanks go to the authors of those documents.