Are there actual use cases for SLH-DSA in the JOSE context at all? I would avoid registering anything wrt SLH-DSA until there is a clear need for the use cases COSE/JOSE cover.
The signatures are quite large (and SLOW) and using them will probably be tricky in some of the current uses cases due to the size increase. Additionally NIST is approving new variants of SLH-DSA, so it may make sense to just hold on and wait until the dusts settles a little bit on this and only then evaluate what are the most appropriate variants that is safe to support (some may not be safe due to the limited use some reduced parameter sets will afford). Simo. On Thu, 2025-10-02 at 09:52 -0500, Orie wrote: > Hi, > > I was hoping to not register many different parameter sets, and was going to > suggest we just register: > > SLH-DSA-SHA2-128s > > I could live with: > > SLH-DSA-SHAKE-128s > > I'm not sure for JOSE and COSE use cases we need both. > More variants of the same algorithm is not helpful for interop. > > If we can get consensus to reduce the set of algorithms this draft registers, > I am strongly in favor of doing that. > > Regards, > > OS > > > On Thu, Oct 2, 2025 at 9:02 AM John Mattsson > <[email protected]> wrote: > > > > > > > > > > Hi, > > > > I am against that this documentstandardizes moreSHA-2 variants thanSHAKE. I > > agree with Arne Padmos that the prefered way forward would be only > > SHAKE-based SLH-DSA [1]. > > > > SHA-3 was designed with side-channel security in mind, whereas SHA-2 is > > significantly harder to protect against side-channels. HMAC, HDKF, MGF, > > etc. are constructions only needed when the hash function has significant > > vulnerabilities/issues such as length-extension, failure to behave like a > > random function, lack of variable-length output, etc. SHA-3 is practically > > much more secure than SHA-2. > > > > An earlier version of SHA-2 SPHINCS+ has security problems and got "fixed" > > into something which I would call quite ugly. I think Section 11of FIPS 205 > > [2]is a very clear example why SHAKE is highly preferred over SHA-2. > > [1]https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/vtMTuE_3u-0/m/80Cvu_HYAAAJ > > [2]https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf > > > > Cheers, > > John Preuss Mattsson > > (As an individual) > > > > On 2024-10-21, 00:24, "[email protected]" <[email protected]> > > wrote: > > > > > > Internet-Draft draft-ietf-cose-sphincs-plus-05.txt is now available. It is a > > > > > > work item of the CBOR Object Signing and Encryption (COSE) WG of the IETF. > > > > > > > > > > > > Title: SLH-DSA for JOSE and COSE > > > > > > Authors: Michael Prorock > > > > > > Orie Steele > > > > > > Rafael Misoczki > > > > > > Michael Osborne > > > > > > Christine Cloostermans > > > > > > Name: draft-ietf-cose-sphincs-plus-05.txt > > > > > > Pages: 11 > > > > > > Dates: 2024-10-20 > > > > > > > > > > > > Abstract: > > > > > > > > > > > > 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 [FIPS-205]. 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. > > > > > > > > > > > > The IETF datatracker status page for this Internet-Draft is: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-cose-sphincs-plus/ > > > > > > > > > > > > There is also an HTML version available at: > > > > > > https://www.ietf.org/archive/id/draft-ietf-cose-sphincs-plus-05.html > > > > > > > > > > > > A diff from the previous version is available at: > > > > > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-cose-sphincs-plus-05 > > > > > > > > > > > > Internet-Drafts are also available by rsync at: > > > > > > rsync.ietf.org::internet-drafts > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > jose mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
