Add LMS/XMSS and statefulness note to QS03 firmware/software signing

[akanthed]

CNSA 2.0 approves LMS and XMSS (NIST SP 800-208) for firmware and software signing and excludes SLH-DSA from NSS use, a scope distinction QS03 didn't cover. Adds a prevention item on this plus the statefulness constraint on LMS/XMSS keys, and the two supporting references.

[akanthed]

CNSA 2.0 approves LMS and XMSS (NIST SP 800-208) for firmware and software signing and excludes SLH-DSA from NSS use, a scope distinction QS03 didn't cover. Adds a prevention item on this plus the statefulness constraint on LMS/XMSS keys, and the two supporting references.

To be clear on scope: I'm not suggesting SLH-DSA is a poor choice generally, only that the NSS distinction wasn't visible in the entry. If item 3 was worded that way deliberately, happy to narrow or drop this.

Small aside: reference 3 currently points at the NSA press-release page. The FAQ v2.1 PDF (Dec 2024, PP-24-4014) has the algorithm table itself, and the Sep 2022 advisory (PP-22-1338) is where the 2030 exclusive-use date for firmware signing actually comes from. Happy to add either if useful.

[nmcitra]

Verified the three load-bearing claims against the cited sources before writing this: LMS/XMSS approved for firmware and software signing per SP 800-208, SLH-DSA not approved for any NSS use, ML-DSA also approved for this use case. All hold, and the FAQ version and document number match. A +3 PR where every claim checks out against primary sources is a good first contribution.

One addition worth a clause: the FAQ approves single-tree LMS and XMSS only — HSS and XMSS^MT, the multi-tree variants, are not approved for NSS. As written, "LMS and XMSS" could send an implementer to HSS, which is the more common library default for high signature counts. Since your item already covers the ML-DSA alternative for exactly that situation, naming the exclusion completes the picture.

The statefulness sentence is the most valuable part of the item — backup, restore, and failover as the paths that silently break the guarantee is the operational detail most write-ups skip. If anything, it could stand to be its own prevention item: as written, item 6 carries three distinct controls (scheme selection, scope caveat, state management), and checklists get used one item at a time. Your call; the substance is right either way.

On your caveat about item 3's wording: QS03 is likely to be restructured — see the merge discussion in #11 and @m-khan-97's offer there to redraft it as the single signature-and-trust entry. Worth coordinating so your item lands in the new shape rather than the old numbering. The content belongs in that entry wherever the numbers end up.

[akanthed]

Thanks for the thorough check — good catch on the HSS/XMSS^MT scope. Pushed a fix: item 6 now explicitly calls out that CNSA 2.0/SP 800-208 approval covers single-tree LMS and XMSS only, and that HSS and XMSS^MT (the common library defaults for high signature counts) are not approved for NSS use.

On the split: leaving item 6 as one combined item for now rather than breaking it into three — happy to revisit if it reads as overloaded in practice.

On #11/#38: noted, and agreed this should land in whatever shape @m-khan-97's redraft settles on rather than the current numbering. I'll hold off on further QS03 edits until #38 merges, then re-home this content (LMS/XMSS approval scope + statefulness note) into the new signature-and-trust entry.