]> mesur.io

mprorock@mesur.io

Tradeverifyd

orie@or13.io

University of the Bundeswehr Munich

Neubiberg Bavaria 85577 Germany hannes.tschofenig@gmx.net

Security CBOR Object Signing and Encryption JOSE COSE PQC FN-DSA This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for FFT (fast-Fourier transform) over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 206 (expected to be published in late 2026 early 2027). It does not define new cryptographic primitives; rather, it specifies how existing FN-DSA mechanisms are serialized for use in JOSE and COSE. This document registers signature algorithms for JOSE and COSE, specifically FN-DSA-512 and FN-DSA-1024. 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 CBOR Object Signing and Encryption Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for FFT (fast-Fourier transform) over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 206 (expected to be published in late 2026 early 2027). FN-DSA (formerly known as Falcon) is a lattice-based digital signature scheme based on the GPV hash-and-sign framework , instantiated over NTRU lattices with fast Fourier sampling techniques . The core hard problem underlying FN-DSA is the SIS (Short Integer Solution) problem over NTRU lattices. FN-DSA (formerly known as Falcon) is a digital signature algorithm based on lattice mathematics. It follows the hash-and-sign design introduced by Gentry, Peikert, and Vaikuntanathan . FN-DSA operates on NTRU lattices and uses fast Fourier techniques to make signature generation compact and efficient. The security of the scheme relies on the hardness of solving certain lattice problems, in particular the Short Integer Solution (SIS) problem. FN-DSA offers:

• Post-quantum security under the assumption that NTRU-SIS remains hard.
• Compactness in key and signature size.
• Efficient operations (roughly O(n log n)).
• A requirement for careful implementation to avoid side-channel leakage (notably Gaussian sampling must be constant-time where applicable).

The sizes of public key, private key, and signature for the parameter sets are the same as in the original Falcon specification: Key Sizes for FN-DSA

Parameter Set	Signature size (bytes)	Public Key size (bytes)	Private Key size (bytes)
FN-DSA-512	666	897	1281
FN-DSA-1024	1280	1793	2305

For a detailed comparison of FN-DSA with ML-DSA and SLH-DSA see . This document defines how FN-DSA is used with JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) .

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.

The FN-DSA Algorithm Family The FN-DSA Signature Scheme is parameterized to support different security levels. This document introduces the registration of the following algorithms in : JOSE Algorithms for FN-DSA

Name	alg	Description
FN-DSA-512	FN-DSA-512	FN-DSA with parameter set 512
FN-DSA-1024	FN-DSA-1024	FN-DSA with parameter set 1024

This document introduces the registration of the following algorithms in : COSE Algorithms for FN-DSA

Name	alg	Description
FN-DSA-512	TBD1 (-54)	CBOR Object Signing Algorithm for FALCON512
FN-DSA-1024	TBD2 (-55)	CBOR Object Signing Algorithm for FALCON1024

FN-DSA Keys The FN-DSA Algorithm Family uses the Algorithm Key Pair (AKP) key type, as defined in Section 3 of . The specific algorithms for FN-DSA, such as FALCON512 and FALCON1024, are defined in this document and are used in the alg value of an AKP key representation to specify the corresponding algorithm. Thumbprints for FN-DSA keys are computed according to the process described in Section 6 of .

Security Considerations The security considerations of , and apply to this specification as well. A detailed security analysis of FN-DSA is beyond the scope of this specification; see for additional details.

Pre-Hash and Hashing Considerations FN-DSA, as specified in , supports both pure and pre-hash modes. This document specifies only the pure mode of FN-DSA for use with JOSE and COSE. This document does not define or register separate HashFN-DSA algorithm identifiers for JOSE or COSE. Doing so would require distinct algorithm registrations and would introduce additional implementation and interoperability complexity. The algorithm identifiers defined in this document therefore refer only to the pure FN-DSA variants. For many COSE use cases, this restriction is acceptable because the application can already structure the signed content in a way that limits the amount of data processed directly by the signature algorithm. In particular, applications that need to sign large payloads, detached content, or remotely held content may use the COSE Hash Envelope mechanism . Hash Envelope can provide operational properties similar to those sought from a pre-hash signature mode, such as reduced data transfer to a signer, reduced buffering requirements, and simplified remote-signing workflows. However, Hash Envelope is not cryptographically identical to a standardized pre-hash variant of FN-DSA. In Hash Envelope, a digest is carried and signed at the COSE layer, whereas in a pre-hash signature algorithm the hashing step is part of the algorithm definition itself. Applications that use Hash Envelope together with FN-DSA need to ensure that the digest is recomputed over the original content and compared with the signed digest before treating the signature as valid for that content. Profiles that rely on this construction SHOULD specify the permitted hash algorithms and the verification procedure explicitly. If future deployment experience shows clear demand for algorithm-level pre-hash semantics in JOSE or COSE, separate registrations for HashFN-DSA could be defined in a future specification.

Validating Public Keys Public keys SHOULD be validated before use (e.g., against encoding constraints). When an AKP algorithm requires or encourages that a key be validated before being used, all algorithm-related key parameters MUST be validated. For FN-DSA public keys, this includes, at a minimum:

• Implementations MUST ensure that alg matches the intended algorithm variant.
• The key representation MUST be of the AKP key type and MUST contain the public key value (pub for JWK, label -1 for COSE_Key).
• The decoded public key value MUST have the expected length for the selected algorithm variant (see ).

Public keys that fail these checks MUST be rejected.

Side-Channel Attacks Implementers should follow best practices to mitigate timing, cache, and power side channels, such as:

• Using constant-time arithmetic
• Maintaining uniform memory access patterns
• Avoiding data-dependent branching or memory indexing

Randomness Considerations All required randomness (e.g. for signature generation) MUST be derived from a cryptographically secure, high-entropy source.

IANA Considerations

New COSE Algorithms IANA is requested to add the following entries to the COSE Algorithms Registry. The following completed registration templates are provided as described in and .

FN-DSA-512

• Name: FN-DSA-512
• Value: TBD1 (requested assignment -54)
• Description: CBOR Object Signing Algorithm for FALCON512
• Capabilities: [kty]
• Change Controller: IETF
• Reference: RFC XXXX
• Recommended: Yes

FN-DSA-1024

• Name: FN-DSA-1024
• Value: TBD2 (requested assignment -55)
• Description: CBOR Object Signing Algorithm for FALCON1024
• Capabilities: [kty]
• Change Controller: IETF
• Reference: RFC XXXX
• Recommended: Yes

New JOSE Algorithms IANA is requested to add the following entries to the JSON Web Signature and Encryption Algorithms Registry. The following completed registration templates are provided as described in .

FN-DSA-512

• Algorithm Name: FN-DSA-512
• Algorithm Description: FN-DSA-512 as described in US NIST FIPS 206.
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFC XXXX
• Algorithm Analysis Documents(s):

FN-DSA-1024

• Algorithm Name: FN-DSA-1024
• Algorithm Description: FN-DSA-1024 as described in US NIST FIPS 206.
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFC XXXX
• Algorithm Analysis Documents(s):

References Normative References JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. The CBOR Object Signing and Encryption (COSE) syntax (see RFC 9052) does not define any direct methods for using hash algorithms. There are, however, circumstances where hash algorithms are used, such as indirect signatures, where the hash of one or more contents are signed, and identification of an X.509 certificate or other object by the use of a fingerprint. This document defines hash algorithms that are identified by COSE algorithm identifiers. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. Tradeverifyd Tradeverifyd This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Module- Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. n.d. 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 IANA IANA Fraunhofer SIT This document defines new COSE header parameters for signaling a payload as an output of a hash function. This mechanism enables faster validation, as access to the original payload is not required for signature validation. Additionally, hints of the hashed payload's content format and availability are defined, providing references to optional discovery mechanisms that can help to find original payload content. Nokia Nokia Nokia DigiCert Entrust Limited The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), detailing the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. n.d. n.d.

Examples

JOSE

Key Pair

Example FN-DSA-512 Private JSON Web Key

Example FN-DSA-512 Public JSON Web Key

JSON Web Signature

Example FN-DSA-512 Decoded Protected Header for a JSON Web Signature

COSE

Key Pair

Example FN-DSA-512 Private COSE Key

Example FN-DSA-1024 Private COSE Key

Example FN-DSA-512 Public COSE Key

Example FN-DSA-1024 Public COSE Key

COSE Sign1

Example FN-DSA-512 COSE Sign1 >, / unprotected / {}, / payload / h'66616b65', / signature / h'39d79a9d52f6abf0dbfcdd2ae28f612741d41637793a3d698542d69d277ba3cf 15cb855a7000913b9badc27925ba438ec42d6ff6cd25193528d1c4647555c6be 6ffd385768dc1b8f1c0ff3989da64c79903f4c6c1fb68922843a7eae3b4d2b16 cfa8301b07c6556df42ecc5a7d32e6bbfad7f7c144630f377d86429867eeb1d7 ffa598e78b443a0fc383bfc962e8f22e92e539432d3ee9e396855ea5396e6aaa 3c1fa95e54fa73f57dd6874ca24f555c7b539172546552fde533dd07033273d5 f2ccae76ec03a7009e58e735667a58e4a7768732e763dce210d62377f2894bd0 1778872dce0f68ae2ce4e529ded268707cd552a3a131c944a7756fc2695a4451 834a673b4df69a1eb9bb2ef4fd29541a7ff206605cd9fa9a4112cba64a01e4be 6c4f2752d9975ab064b8d7eea8a5f8c407a25ca6ea70f2ef4cbda113ad2bdf1a e5e0b2556cc513c5d7e47ef0a79f9df3d6b7ea2ec69f192211b918c1d414e772 364ca57713459e23d0f8bca12d2213185ece7d58cb0aee9a32f56c28d5759192 c8ec3147be61aa122f8ca4ad710dfe72caef608cfb8ea4ce7c0cb6e8af22eddc cd896fa553ec1184632107d276dc896267ad80d5151d0e6204470c0233a733cc b7d3564413cfc26dc48d216871c09118f6d9b1c49f363e32c1347c647e851188 4a58f6cda5797191da36245f5418b6110f69d061c920840cf3ad67010c6593c5 5ba37d8b4b72e91a72e6a872379db25e3f07bbba4c91765b1f1f498b2e61f64c 4da4b2486cf878c76a39b5c7ff53ca036c5ae269e73f37854695067f9d85aa78 b6e5262a25501d2c8b43923f84195bade108044a270e55ed379ae3193ed115ba 76cbec7af6314e71a64c3bceae54d7c0135e8c27ae47a61badb9979c73b10647 3919308cb58efcf27b1537896e86cf182c42' ]) ]]>

Example FN-DSA-1024 COSE Sign1 >, / unprotected / {}, / payload / h'66616b65', / signature / h'3a12ef94a269b3d76e22c8bb373e940fa78db86f3a5b79544a415eab87f6bea0 7535d1a75c0c3f1913399592ee4495013006cf21eaf42858bde3dc87d4c9d0df 3a684a37f876f42e1b5a8208f46da8cddddf737f7a6c5d50fad220da712d62d7 f3a2671c850366c2756133054a9f54d7109533fba24edbed433cddca8d7226ef ec103d5c09153ddba53e4f4afbc330b5f1614f683c8da9c543675fdd6329aca8 f9e489a69b96df99b886f702485bef87e36a41094682702083aa81c01498b09a a3b3fb0f9122bed7f8d55640bbe95e6bd2a0a46274582d2b189ae5c95dc31b40 31399da49a510f7d5adb451d7162caff632a5e6d8a6b24c465d4794e6e3a9641 b3647720fa6f4d8f8f9d56c424edabff28d1e81e640930452b111244c6a0f0c9 c1b4acee90ed854f7d8acb50ea1f1c9379ca8abb9db6a5b4c9ed685c6689db5a 72a919ca6f504e37a5f98da26db24b229d6ee4e94b24519c47c25090eddc6363 adb11bc3154c627a9191af9ba5ca3e9494c0d12ef74ac3306a0b9419aac0f575 19d60716567f52ce93fdf08eb4db8e5c2d0a6e37b47aac654db5317c97a22134 3e5ffeb26596c141b60b6ac3706a4ef4b7e27b3666e3ed13c932389170a36ede fe0dca4ee4ea26b99ddb363499469daa44d192dd3f796dc8720c86d60c864506 efc9f59f46ddff7c3f4f0ea75ad4c062bfc89b7021470a3e8baaa8ea2bf1aad4 539565b04ba878b45b67b280c26e5939c6497570b31df3470386f84f5164d717 ef7d37659952e2d0129356cefc7118e9ec72846aff9b0502e72d8d6190c4cf2d da71f5a79dd396a55f34dab0bd9e28af9960c7197cb2c175fe10114cb2218936 d7eca6b808efc22f8943f1126d7b4f138f4c1408d6ff5865731936da452b3549 335ac02e5abaef2ec9a345d8dd8722e9006cd980c4473a6854237cc49b5d3b55 e998c258ca34edf1e72d4b8c1130e3e6eb1ad6ee2ac9aafc838125622d8be28c 9288269de3c0c0a04ec4fab8cdba096b83018fecd5e313faf149b7bd8e8495d0 807388bb6b4d5192e2cb84c2987851cd208189d84f152550e3d9b104205a236c 92a30d901796df2c63c86620d82bd88302815d2c15e6b222d7fa678ebf65e1de e7522e8eb4bfa584ebd9a8e7269377e34a9db2653773835c3a867507d8ac30ec d366c356b3af43569244bb73ad2b81c9337e5877648e49daa1a8dc38506b76b7 6dfbb1f1e225b53a6eb1249137a0e17e72efbe40d34a8a0aaad7c0d986b6e7ab 89537c56c60d444b61add8cff00b371d60ada9ef3b0df5cb3353470578f8c9c9 f3dff8cbcb5306be6f7b6a66290ffa54d3958e2c71eefa767f83f35d21104e36 911767db8e454d37f551f12ecc148b3fe5d8ba95ad0eae06a719961d4822d536 994699d2999c7982a4113447619f67ea52e48f7a89780852042c73ce356d43c9 11698c7f419d5b4ae384bcf2e3bb2b846b37906523950a5e315d7b3989162ed6 5299859ce24a51bcef8724d62852d3ded76e7cc89ac9865393ce7ef33ce85a2a 0df19e7ad04e7eab47dcb7609e06aaa6c5702630a3af4cb054d17dbbfb582e3f 825573b44bb7053641dad24ecca10afdfd8d29f5c7484a3f210a54d96fceb0b0 ffe7dd89fabe4c52e688e1d65425eac9497bb9b213ccd3efd29225a026760629 1b755a44e64b4690e28b840e1280a49b1b6e4b46bad677c99a62c91de45c7ed0 68897ee8c3071b9913e0a5653e0a5f165204c8082a97141ab64d41a7b9ccc76c 9dc82c1044f968b84573c74f7db38da76a349d08579339a1ae40' ]) ]]>

Acknowledgments We would like to especially thank David Balenson for careful review of approaches taken in this document. We would also like to thank Michael B. Jones for guidance in authoring.

Contributors Google

rafaelmisoczki@google.com

IBM

osb@zurich.ibm.com

NXP

christine.cloostermans@nxp.com