[Defect]: LMOTS pattern uses treeHeight semantics and misses W (RFC 8554 / SP 800-208)

[Mehrn0ush]

Describe the defect

In schema/cryptography-defs.json, the LMS family includes an LMOTS variant pattern that appears to encode parameters in a way that does not line up with how LM-OTS parameter sets are identified in the referenced standards.

Current registry patterns:

• LMS[_{hashFunction}][_M{bytesPerNode}][_H{treeHeight}]
• LMOTS[_{hashfun}][_N{bytespernode}][_H{treeheight}]

For LMOTS, the pattern currently includes _H{treeheight} and uses _N{bytespernode}, while omitting W. This seems inconsistent with standard LMOTS parameter-set identifiers (which include N and W alongside the hash function).

Additional context

References

• RFC 8554 (LMS Hash-Based Signatures)

  • Table 1 (LMOTS parameter sets) lists columns including H (hash function), n, w, and p, and shows names such as LMOTS_SHA256_N32_W4. (RFC 8554, Table 1)
  • Table 2 (LMS parameter sets) lists columns including H (hash function), m, and h (tree height), and shows names such as LMS_SHA256_M32_H5. (RFC 8554, Table 2)

• NIST SP 800-208

  • Section 4 (“Leighton-Micali Signatures (LMS) Parameter Sets”) includes:
    • Table 1 (LM-OTS parameter sets for SHA-256): n, w, p and names like LMOTS_SHA256_N32_W4
    • Table 2 (LMS parameter sets for SHA-256): m, h and names like LMS_SHA256_M32_H5
    • Tables 3–8 extend the same structure for other approved hash functions.

_H{treeheight} is problematic for LMOTS

Tree height (h) is an LMS-level parameter (Merkle tree height). LM-OTS is a one-time signature and does not have a tree height parameter. In the RFC tables, H in the LMOTS table refers to the hash function, not height—so using _H{treeheight} in the LMOTS pattern may cause confusion for consumers that interpret these patterns.

Note on p

p appears in the LMOTS tables, but standard LMOTS parameter-set names typically encode N and W (e.g., ..._N32_W4). A pattern capturing hash + N + W is usually sufficient, with p optionally included only if needed.

Question

Is the LMOTS variant.pattern intended to reflect standard LMOTS parameter-set identifiers? If yes, would maintainers prefer encoding something closer to hash + N + W (and optionally p) rather than tree-height terminology?