| Internet-Draft | FN-DSA in the CMS | November 2025 |
| Van Geest & Turner | Expires 8 May 2026 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://seanturner.github.io/cms-fn-dsa/draft-turner-lamps-cms-fn-dsa.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-turner-lamps-cms-fn-dsa/.¶
Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME Working Group mailing list (mailto:spasm@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at https://www.ietf.org/mailman/listinfo/spasm/.¶
Source for this draft and an issue tracker can be found at https://github.com/seanturner/cms-fn-dsa.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 8 May 2026.¶
Copyright (c) 2025 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 (https://trustee.ietf.org/license-info) 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.¶
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 [FIPS205], 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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:¶
AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
SEQUENCE {
algorithm ALGORITHM-TYPE.&id({AlgorithmSet}),
parameters ALGORITHM-TYPE.
&Params({AlgorithmSet}{@algorithm}) OPTIONAL
}
¶
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 [CSOR], and are reproduced here for convenience.¶
sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithms(4) 3 }
id-fn-dsa-512 OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-fn-dsa-1024 OBJECT IDENTIFIER ::= { sigAlgs TBD }
¶
[RFC5652] 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 [RFC8032], ML-DSA [FIPS20], and SLH-DSA [FIPS205], 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 [RFC8419], SLH-DSA [RFC9814], and ML-DSA [RFC9882] 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.¶
[RFC5652] 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 Section 5.4 of [RFC5652],
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 [X690] encoding of the SignedAttrs value
contained in the SignerInfo's signedAttrs field. As described in
Section 5.4 of [RFC5652], 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.¶
Section 4 of [RFC9814] 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.¶
When using FN-DSA, the fields of a SignerInfo are used as follows:¶
digestAlgorithm:Per Section 5.3 of [RFC5652], the digestAlgorithm field identifies
the message digest algorithm used by the signer, and any associated
parameters. Each FN-DSA parameter set ...¶
SHA-512 [FIPS180] 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 [RFC5754] digest algorithm identifier is used and the parameters field MUST be omitted. When SHAKE256 is used, the id-shake256 [RFC8702] 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 Table 1 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.¶
| 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
Section 2:¶
| 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 [FIPS206], and the
signature-verification operation is specified in Section X.X of [FIPS206].
Note that Section 5.6 of [RFC5652] places further requirements on the
successful verification of a signature.¶
The security considerations in [RFC5652] 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 [FIPS206] 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 [BD23]. 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 [RFC6211] SHOULD be included in signed
attributes.¶
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 Section 5.3 of [RFC5652],
the much smaller set of signed attributes are sent to the device for
signing.¶
For the ASN.1 module in Appendix A, 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):¶
| Decimal | Description | Reference |
|---|---|---|
| TBD | id-mod-fn-dsa-2026 | This RFC |
<CODE BEGINS>
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
<CODE ENDS>
¶
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:¶
This document was heavily influenced by [RFC8419], [RFC9814], and [RFC9881]. Thanks go to the authors of those documents.¶