Use of Composite FN-DSA Signatures in TLS 1.3

Status of This Memo

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 13 November 2026.¶

Copyright Notice

Copyright (c) 2026 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.¶

Table of Contents

1. Introduction

The advent of quantum computing poses a significant threat to current cryptographic systems. During the transition to post-quantum cryptography (PQC), cautious implementers may opt to combine cryptographic algorithms such that an attacker would need to break all of them simultaneously to compromise the protected data. These mechanisms are referred to as Post-Quantum/Traditional (PQ/T) Hybrids [RFC9794].¶

One practical way to implement a hybrid signature scheme is through a composite signature algorithm. In this approach, the composite signature consists of two signature components, each produced by a different signature algorithm.¶

FN-DSA [FIPS206] is a post-quantum signature scheme standardized by NIST. This memo specifies how a composite FN-DSA signature can be negotiated for authentication in TLS 1.3 via the "signature_algorithms" and "signature_algorithms_cert" extensions.¶

The composite algorithms defined herein are based on the framework specified in [I-D.chen-lamps-fndsa-composite-sigs]. A key design goal of this specification is to ensure consistency across the emerging post-quantum ecosystem. To that end, the selection of algorithm pairings in this document is intentionally aligned with the choices made for ML-DSA in draft-ietf-lamps-pq-composite-sigs. This creates two clear security tiers, allowing organizations to treat FN-DSA and ML-DSA composites at the same security level as interchangeable from a policy perspective.¶

2. Composite FN-DSA SignatureSchemes

As defined in [RFC8446], the SignatureScheme namespace is used for the negotiation of signature schemes. This document adds new SignatureScheme values for composite FN-DSA, organized into two tiers that mirror the ML-DSA composite strategy.¶

enum {
    /* Tier 1 Composites (FN-DSA-512 based, mimicking ML-DSA-44) */
    fndsa512_rsa2048_pss_sha256(TBD1),
    fndsa512_ecdsa_p256_sha256(TBD2),
    fndsa512_ed25519(TBD3),

    /* Tier 2 Composites (FN-DSA-1024 based, mimicking ML-DSA-87) */
    fndsa1024_rsa3072_pss_sha512(TBD4),
    fndsa1024_ecdsa_p384_sha512(TBD5),
    fndsa1024_ecdsa_p521_sha512(TBD6),
    fndsa1024_ecdsa_brainpoolP384r1_sha512(TBD7),
    fndsa1024_ed448(TBD8),

} SignatureScheme;

Composite FN-DSA is treated as an opaque signature algorithm, similar to the "PureEdDSA" algorithms in TLS 1.3 (Section 4.2.3 of [RFC8446]). Any hash functions used are internal to the composite algorithm itself, as specified in [I-D.chen-lamps-fndsa-composite-sigs].¶

When a composite FN-DSA signature scheme is used in TLS, the signing and verification operations MUST be performed on the input data as constructed by TLS (Section 4.4.3 of [RFC8446]). This input is then passed to the composite signature primitive, which applies its own internal domain separation.¶

When a composite FN-DSA SignatureScheme is negotiated, the end-entity certificate presented in the TLS handshake MUST contain a public key compatible with that SignatureScheme.¶

The schemes defined in this document MUST NOT be used in TLS 1.2 [RFC5246].¶

3. Signature Algorithm Restrictions

The composite algorithms defined in this document are suitable for use in both the signature_algorithms and signature_algorithms_cert extensions. Consistent with TLS 1.3's requirements, all defined RSA-based composites use the RSASSA-PSS padding scheme for handshake signatures. Certificates MAY be signed with composites using RSASSA-PKCS1-v1_5, but these are not negotiated for use in the TLS CertificateVerify message.¶

4. Selection Criteria for Composite Signature Algorithms

The composite signatures specified in this document are a curated set of cryptographic pairs, directly adopted from [I-D.chen-lamps-fndsa-composite-sigs]. The selection process was guided by a single, overriding principle:¶

• Strictly Mirroring ML-DSA Composite Strategy: The pairings for fndsa512 are identical to those for ML-DSA-44, and the pairings for fndsa1024 are identical to those for ML-DSA-87, as defined in draft-ietf-lamps-pq-composite-sigs.¶

This prescriptive approach ensures a consistent, two-tiered security model across the PQC signature landscape, simplifying policy development and promoting interoperability.¶

5. Security Considerations

The security considerations discussed in [I-D.chen-lamps-fndsa-composite-sigs] apply. The primary goal is to provide hybrid security, where the composite signature remains secure as long as at least one component algorithm remains secure.¶

Composite signature schemes do not in general preserve strong unforgeability (SUF-CMA) once the traditional component is broken. This does not impact TLS, which relies on existential unforgeability (EUF-CMA).¶

TLS clients that support both post-quantum and traditional-only signature algorithms are vulnerable to downgrade attacks. The continuity mechanism defined in [I-D.sheffer-tls-pqc-continuity] can be used to mitigate this risk.¶

6. IANA Considerations

This document requests new entries to the "TLS SignatureScheme" registry, according to the procedures in [TLSIANA].¶

7. References

Appendix A. Acknowledgments

This document also draws on draft-reddy-tls-composite-mldsa. Thanks to the authors of that document.¶

Authors' Addresses