]> mesur.io

mprorock@mesur.io

Transmute

orie@transmute.industries

Google

rafaelmisoczki@google.com

IBM

osb@zurich.ibm.com

NXP

christine.cloostermans@nxp.com

Security CBOR Object Signing and Encryption JOSE COSE PQC SPHINCS+ SLH-DSA This document describes JOSE and COSE serializations for SLH-DSA, which was derived from SPHINCS+, a Post-Quantum Cryptography (PQC) based digital signature scheme. This document does not define any new cryptography, only seralizations of existing cryptographic systems described in . Note to RFC Editor: This document should not proceed to AUTH48 until NIST completes paramater tuning and selection as a part of the PQC standardization process. 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 describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Stateless Hash-Based Digital Signature Standard (SLH-DSA), which was derived from Version 3.1 of SPHINCS+, a Post-Quantum Cryptography (PQC) based digital signature scheme. This document does not define any new cryptography, only serializations of existing cryptographic systems described in . This document builds on the Algorithm Key Pair (AKP) type as defined in . The AKP type enables flexible representation of keys used across different post-quantum cryptographic algorithms, including SLH-DSA.

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 SLH-DSA Algorithm Family The SLH-DSA Signature Scheme is parameterized to support different security levels. This document requests the registration of the following algorithms in : JOSE algorithms for SLH-DSA

Name	alg	Description
SLH-DSA-SHA2-128s	SLH-DSA-SHA2-128s	JSON Web Signature Algorithm for SLH-DSA-SHA2-128s
SLH-DSA-SHAKE-128s	SLH-DSA-SHAKE-128s	JSON Web Signature Algorithm for SLH-DSA-SHAKE-128s
SLH-DSA-SHA2-128f	SLH-DSA-SHA2-128f	JSON Web Signature Algorithm for SLH-DSA-SHA2-128f

This document requests the registration of the following algorithms in : COSE algorithms for SLH-DSA

Name	alg	Description
SLH-DSA-SHA2-128s	TBD (requested assignment -51)	CBOR Object Signing Algorithm for SLH-DSA-SHA2-128s
SLH-DSA-SHAKE-128s	TBD (requested assignment -52)	CBOR Object Signing Algorithm for SLH-DSA-SHAKE-128s
SLH-DSA-SHA2-128f	TBD (requested assignment -53)	CBOR Object Signing Algorithm for SLH-DSA-SHA2-128f

SLH-DSA Keys Private and Public Keys are produced to enable the sign and verify operations for each of the SLH-DSA Algorithms. The SLH-DSA Algorithm Family uses the Algorithm Key Pair (AKP) key type, as defined in . This ensures compatibility across different cryptographic algorithms that use AKP for key representation. The specific algorithms for SLH-DSA, such as SLH-DSA-SHA2-128s, SLH-DSA-SHAKE-128s, and SLH-DSA-SHA2-128f, are defined in this document and are used in the alg value of an AKP key representation to specify the algorithm that corresponds to the key. Like ML-DSA keys, SLH-DSA keys use the AKP Key Type. The thumbprints for SLH-DSA keys are also computed according to the process described in

Security Considerations The security considerations of , and applies to this specification as well. A detailed security analysis of SLH-DSA is beyond the scope of this specification, see for additional details. The following considerations apply to all parameter sets described in this specification.

Validating public keys All algorithms in that operate on public keys require first validating those keys. For the sign, verify and proof schemes, the use of KeyValidate is REQUIRED.

Side channel attacks Implementations of the signing algorithm SHOULD protect the secret key from side-channel attacks. Multiple best practices exist to protect against side-channel attacks. Any implementation of the SLH-DSA signing algorithms SHOULD utilize the following best practices at a minimum:

• Constant timing - the implementation should ensure that constant time is utilized in operations
• Sequence and memory access persistance - the implementation SHOULD execute the exact same sequence of instructions (at a machine level) with the exact same memory access independent of which polynomial is being operated on.
• Uniform sampling - care should be given in implementations to preserve the property of uniform sampling in implementation and to prevent information leakage.

Randomness considerations It is recommended that the all nonces are from a trusted source of randomness.

IANA Considerations

Additions to Existing Registries

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 RFC9053 and RFC9054.

SLH-DSA-SHA2-128s

• Name: SLH-DSA-SHA2-128s
• Value: TBD (requested assignment -51)
• Description: CBOR Object Signing Algorithm for SLH-DSA-SHA2-128s
• Capabilities: [kty]
• Reference: RFC XXXX
• Recommended: Yes

SLH-DSA-SHAKE-128s

• Name: SLH-DSA-SHAKE-128s
• Value: TBD (requested assignment -52)
• Description: CBOR Object Signing Algorithm for SLH-DSA-SHAKE-128s
• Capabilities: [kty]
• Reference: RFC XXXX
• Recommended: Yes

SLH-DSA-SHA2-128f

• Name: SLH-DSA-SHA2-128f
• Value: TBD (requested assignment -53)
• Description: CBOR Object Signing Algorithm for SLH-DSA-SHA2-128f
• Capabilities: [kty]
• 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 RFC7518.

SLH-DSA-SHA2-128s

• Algorithm Name: SLH-DSA-SHA2-128s
• Algorithm Description: SLH-DSA-SHA2-128s as described in FIPS 205.
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Value registry: Algorithms
• Specification Document(s): RFC XXXX
• Algorithm Analysis Documents(s):

SLH-DSA-SHAKE-128s

• Algorithm Name: SLH-DSA-SHAKE-128s
• Algorithm Description: SLH-DSA-SHAKE-128s as described in FIPS 205.
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Value registry: Algorithms
• Specification Document(s): RFC XXXX
• Algorithm Analysis Documents(s):

SLH-DSA-SHA2-128f

• Algorithm Name: SLH-DSA-SHA2-128f
• Algorithm Description: SLH-DSA-SHA2-128f as described in FIPS 205.
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Value registry: Algorithms
• Specification Document(s): RFC XXXX
• Algorithm Analysis Documents(s):

References Normative References IANA IANA 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 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. mesur.io Transmute Google IBM NXP This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Module- Lattice-Based Digital Signature Standard (ML-DSA), which was derived from Dilithium, a Post-Quantum Cryptography (PQC) based digital signature scheme. This document does not define any new cryptography, only seralizations of existing cryptographic systems described in [FIPS-204]. Note to RFC Editor: This document should not proceed to AUTH48 until NIST completes paramater tuning and selection as a part of the PQC (https://csrc.nist.gov/projects/post-quantum-cryptography) standardization process. 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 n.d. n.d.

Examples

JOSE

Key Pair

Example SLH-DSA-SHA2-128s Private JSON Web Key

Example SLH-DSA-SHA2-128s Public JSON Web Key

Thumbprint The thumbprint is computed as described in

JSON Web Signature

Example SLH-DSA-SHA2-128s Decoded Protected Header

Example SLH-DSA-SHA2-128s Compact JSON Web Signature

COSE

Key Pair

Example SLH-DSA-SHA2-128s Public COSE Key

Thumbprint URI TODO

COSE Sign 1

Example SLH-DSA-SHA2-128s COSE Sign 1 > / unprotected / {}, / payload / h'66616b65', / signature / h'53e855e8...0f263549' ] ) ]]>

Acknowledgments TODO acknowledge.