Consider supporting LMS and XMSS

[mkannwischer]

pq-code-package/tsc#101 points out that LMS and XMSS are allowed by CNSA 2.0.

They share significant code with SPHINCS+, so it could be an option to add support to slhdsa-c at some point.

What do you think @mjosaarinen?
Would there be interest form liboqs @dstebila, @praveksharma?

[dstebila]

We do have LMS and XMSS in liboqs, using implementations directly written for liboqs (adapted from existing reference implementations). If PQCP eventually had LMS and/or XMSS in slhdsa-c or elsewhere with ongoing support, we'd consider switching to them.

[mjosaarinen]

My observation has been that there is less shared code between these algorithms than one might think, mostly just the hash functions themselves. For example, while SLH-DSA has a component named XMSS, its implementation differs algorithmically from the "real" XMSS in SP 800-208; the latter traverses the Merkle tree in a specific order, which should be used to minimize the number of hash calls in a stateful implementation. In contrast, the XMSS in SLH-DSA is completely randomized.
The second issue is that LMS and XMSS are not nearly as well specified as SLH-DSA (SP 800-208 just offers parameter set tables and refers to RFC 8391 and RFC 8554 for algorithmic details, and these are just not as clear and complete as those in FIPS 205.) The description for signature verification is quite complete for both LMS and XMSS, but private key format / process descriptions are not. This lack of full specification is one of the main reasons why it makes sense to use code derived from the reference implementations -- so that private keys can be transferred, etc.