SLH-DSA for JOSE and COSE

SLH-DSA for JOSE and COSE 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 SLH-DSA is derived from Version 3.1 of SPHINCS+, as noted in . SPHINCS+ is one of the post quantum cryptography algorithms selected in . TODO: Add complete examples for SLH-DSA-SHA2-128s, SLH-DSA-SHAKE-128s, SLH-DSA-SHA2-128f... ( all of them? really?)

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 paramaterized to support different security level. 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

The SLH-DSA Key Type Private and Public Keys are produced to enable the sign and verify opertaions for each of the SLH-DSA Algorithms. This document requests the registration of the following key types in : JSON Web Key Type for SLH-DSA

Name	kty	Description
SLH-DSA	SLH-DSA	JSON Web Key Type for the SLH-DSA Algorithm Family.

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

Name	kty	Description
SLH-DSA	TBD (requested assignment 8)	COSE Key Type for the SLH-DSA Algorithm Family.

Security Considerations The following considerations SHOULD apply to all parmeter sets described in this specification, unless otherwise noted. Care should be taken to ensure "kty" and intended use match, the algorithms described in this document share many properties with other cryptographic approaches from related families that are used for purposes other than digital signatures.

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 the Sphincs+ 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 implemention 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

SLH-DSA-SHA2-128s

Name: SLH-DSA-SHA2-128s
Label: TBD (requested assignment -51)
Value type: int
Value registry:
Description: CBOR Object Signing Algorithm for SLH-DSA-SHA2-128s

SLH-DSA-SHAKE-128s

Name: SLH-DSA-SHAKE-128s
Label: TBD (requested assignment -52)
Value type: int
Value registry:
Description: CBOR Object Signing Algorithm for SLH-DSA-SHAKE-128s

SLH-DSA-SHA2-128f

Name: SLH-DSA-SHA2-128f
Label: TBD (requested assignment -53)
Value type: int
Value registry:
Description: CBOR Object Signing Algorithm for SLH-DSA-SHA2-128f

New COSE Key Types

SLH-DSA

Name: SLH-DSA
Label: TBD (requested assignment 8)
Value type: int
Value registry:
Description: COSE Key Type for the SLH-DSA Algorithm Family

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
Description: JSON Web Signature Algorithm for 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): https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.ipd.pdf

SLH-DSA-SHAKE-128s

Algorithm Name: SLH-DSA-SHAKE-128s
Description: JSON Web Signature Algorithm for 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): https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.ipd.pdf

SLH-DSA-SHA2-128f

Algorithm Name: SLH-DSA-SHA2-128f
Description: JSON Web Signature Algorithm for 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): https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.ipd.pdf

New JOSE Key Types IANA is requested to add the following entries to the JSON Web Key Types Registry. The following completed registration templates are provided as described in RFC7518 RFC7638.

SLH-DSA

"kty" Parameter Value: SLH-DSA
Key Type Description: JSON Web Key Type for the SLH-DSA Algorithm Family.
JOSE Implementation Requirements: Optional
Change Controller: IETF
Specification Document(s): RFC XXXX

New JSON Web Key Parameters IANA is requested to add the following entries to the JSON Web Key Parameters Registry. The following completed registration templates are provided as described in RFC7517, and RFC7638.

ML-DSA Public Key

Parameter Name: pub
Parameter Description: Public or verification key
Used with "kty" Value(s): SLH-DSA
Parameter Information Class: Public
Change Controller: IETF
Specification Document(s): RFC XXXX

ML-DSA Secret Key

Parameter Name: priv
Parameter Description: Secret, private or signing key
Used with "kty" Value(s): SLH-DSA
Parameter Information Class: Private
Change Controller: IETF
Specification Document(s): RFC XXXX

References Normative References JSON Object Signing and Encryption (JOSE) IANA CBOR Object Signing and Encryption (COSE) IANA Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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 Stateless Hash-Based Digital Signature Standard n.d. Selected Algorithms 2022 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 URI TODO

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 Private COSE Key

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

Thumbprint URI TODO

COSE Sign 1

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

Example SLH-DSA-SHA2-128s COSE Sign 1

Acknowledgments TODO acknowledge.