Add RFC 9802 HSS/LMS and XMSS/XMSS^MT X.509 certificate verification

Wires wolfCrypt's stateful hash-based signature implementations into
the X.509 parse and verify paths per RFC 9802. Parsing, loading into a
WOLFSSL_CERT_MANAGER, and ConfirmSignature now recognise:

  * id-alg-hss-lms-hashsig    1.2.840.113549.1.9.16.3.17
  * id-alg-xmss-hashsig       1.3.6.1.5.5.7.6.34
  * id-alg-xmssmt-hashsig     1.3.6.1.5.5.7.6.35

with parameters absent per RFC 9802 sec 2 and no pre-hash of the TBS.
Scope is verify-only on WOLFSSL_HAVE_LMS / WOLFSSL_HAVE_XMSS.

wolfCrypt-level changes:
  * wc_LmsKey_ImportPubRaw auto-derives the parameter set from
    u32str(L) || lmsType || lmOtsType when key->params == NULL, and
    validates against pre-set params when they are set.
  * wc_LmsKey_GetSigLen and wc_XmssKey_GetSigLen now NULL-check
    key->params (matches sibling GetPubLen / GetPrivLen).
  * wc_XmssKey_ImportPubRaw_ex is new: derives params from the
    4-byte OID prefix of a raw RFC 8391 public key, with an
    is_xmssmt hint to disambiguate the overlapping OID namespaces.
    Accepts INITED, PARMSET, OK and VERIFYONLY states; rejects a
    contradictory is_xmssmt hint when params are already set.

X.509 wiring in asn.c (anchored on the new SLH-DSA landmarks after
upstream's SPHINCS+ -> SLH-DSA replacement):
  * New OID arrays sigHssLmsOid / sigXmssOid / sigXmssMtOid + key
    counterparts.
  * GetObjectId / oidSigType / oidKeyType dispatch.
  * StoreKey guard extended; GetCertKey switch handles the three
    new keyOIDs.
  * IsSigAlgoECC / SigOidMatchesKeyOid / HashForSignature updated
    to omit AlgorithmIdentifier parameters and skip pre-hashing.
  * SignatureCtx union gets LmsKey / XmssKey members; FreeSignatureCtx
    handles cleanup.
  * Three ConfirmSignature states (KEY / DO / CHECK) gain LMS and
    XMSS / XMSS^MT cases.

scripts/asn1_oid_sum.pl gains the three OIDs; oid_sum.h regenerated
with HSS_LMSk / XMSSk / XMSSMTk and CTC_HSS_LMS / CTC_XMSS / CTC_XMSSMT
plus the manually-curated WOLFSSL_ACME_OID block reapplied.

enum cert_enums reserves HSS_LMS_KEY / XMSS_KEY / XMSSMT_KEY (36/37/38)
for future cert-gen support, slotting after SLH_DSA_SHAKE_256F_KEY.

Tests in test_rfc9802_x509_verify exercise:
  * 9 Bouncy Castle 1.81-generated fixtures (LMS h5/w4 and h10/w8;
    HSS L2_H5_W8 and L3_H5_W4; XMSS H=10 and H=16; XMSS^MT 20/2,
    20/4 and 40/8) plus a CA->leaf LMS chain.
  * wc_ParseCert with OID assertions, full
    wolfSSL_CertManagerVerifyBuffer against a self-installed trust
    anchor, signature-byte tamper, TBSCertificate-interior tamper at
    the midpoint of [certBegin, sigIndex), KeyUsage extension presence.
  * wolfCrypt-level negative tests: unknown lmsType / lmOtsType,
    unknown XMSS/XMSS^MT OID, truncated input, NULL args, GetSigLen
    on a key with no params set, partial-write invariant on length
    mismatch (key->params stays NULL), and PARMSET-state mismatch
    (OID prefix or is_xmssmt hint disagreeing with set params).
  * X.509-level negative: cross-OID mismatch between SPKI and outer
    signatureAlgorithm.

All fixtures carry BasicConstraints (CA:TRUE on issuers, CA:FALSE on
leaves) and KeyUsage per RFC 9802 sec 3 / RFC 5280 sec 4.2.1.9. BC's
default XMSS / XMSS^MT encoding uses pre-standard ISARA OIDs and an
OCTET STRING SPKI wrapper, so the fixture generator overrides both to
match RFC 9802.

Verified across configure permutations:
  * default (no LMS/XMSS)
  * --enable-lms
  * --enable-xmss
  * --enable-lms --enable-xmss
  * --enable-lms --enable-xmss --enable-certgen

Out of scope: cert generation, TLS 1.3 SignatureScheme, OpenSSL compat
shims (wolfSSL_LMS_*), OCSP/CRL signed with these algorithms.

https://claude.ai/code/session_01SnSQMb145Hkyyf7hQQQ8cq

RFC 9802: tighten _ex semantics, more negative tests

wc_XmssKey_ImportPubRaw_ex
  * Hold the auto-derived params / oid / is_xmssmt in locals and only
    commit them to the key after the public-key length check passes,
    so a length mismatch leaves an INITED key untouched. Mirrors the
    same fix applied to wc_LmsKey_ImportPubRaw earlier.
  * Reject WC_XMSS_STATE_OK. Importing public-key bytes when private
    material is already loaded would silently desync priv/pub; INITED,
    PARMSET and VERIFYONLY are still accepted.
  * Drop redundant (int) cast on the byte-typed key->is_xmssmt field
    in the consistency check.
  * Replace colloquial "compiled out" comments with the project's
    "disabled at compile time" wording.

Tests
  * Partial-write invariant for XMSS _ex: a length mismatch after a
    valid OID prefix returns BUFFER_E and leaves key.params NULL.
  * is_xmssmt disambiguation: feeding the same 4-byte OID prefix
    (0x00000001, valid in both XMSS and XMSS^MT tables) with hint=0
    vs hint=1 lands in different parameter sets and persists distinct
    is_xmssmt values, locking in that the hint actually drives the
    table selection.
  * Lenient-state positive test: re-importing the same public key
    into a VERIFYONLY key succeeds, exercising the lenient-state
    branch that complements the OID/hint mismatch rejection.

https://claude.ai/code/session_01SnSQMb145Hkyyf7hQQQ8cq

RFC 9802: split LMS / XMSS X.509 tests; add XMSS chain fixture

The unified test_rfc9802_x509_verify worked when both --enable-lms and
--enable-xmss were on, but a user with only one of the two would still
see the test registered (just compiled to a no-op). Split it into two
functions, test_rfc9802_lms_x509_verify (group "lms") and
test_rfc9802_xmss_x509_verify (group "xmss"), so each runs only when
its feature is built and is filterable individually via --group.

Also add an XMSS CA -> leaf chain fixture (bc_xmss_chain_ca.der,
bc_xmss_chain_leaf.der) generated with Bouncy Castle, and a
rfc9802_xmss_chain_verify helper that mirrors the existing LMS chain
verify: load CA as a trust anchor, verify leaf, then re-verify with no
CA installed and assert failure.

https://claude.ai/code/session_01SnSQMb145Hkyyf7hQQQ8cq

RFC 9802: add BC-native LMS cert as cross-impl interop gate

For HSS/LMS, Bouncy Castle's stock X.509 path is already RFC 9802-
compliant: JcaContentSignerBuilder("LMS") emits id-alg-hss-lms-hashsig
(1.2.840.113549.1.9.16.3.17) with absent parameters, and BC's
SubjectPublicKeyInfoFactory carries the raw RFC 8554 public key bytes
directly in the BIT STRING. (BC's XMSS / XMSSMT path still uses
pre-standard private OIDs and an XMSSKeyParams parameters structure,
checked against bc-java main as of May 2026, so the fixtures for those
algorithms still need our Rfc9802Signer override.)

Add bc_lms_native_bc_root.der, generated through BC's stock
JcaContentSignerBuilder + JcaX509v3CertificateBuilder with no
overrides, and pull it into the LMS test list. This is the cross-
impl gate that catches drift in the RFC 9802 encoding wolfSSL accepts:
if BC ships a fully native LMS cert today and we can't verify it,
something has regressed locally.

https://claude.ai/code/session_01SnSQMb145Hkyyf7hQQQ8cq

Author: claude

certs/include.am

@@ -161,6 +161,8 @@ include certs/falcon/include.am
 include certs/rsapss/include.am
 include certs/dilithium/include.am
 include certs/slhdsa/include.am
+include certs/lms/include.am
+include certs/xmss/include.am
 include certs/rpk/include.am
 include certs/acert/include.am
 include certs/mldsa/include.am

certs/lms/bc_hss_L2_H5_W8_root.der

@@ -0,0 +1,12 @@
+# vim:ft=automake
+# All paths should be given relative to the root
+#
+
+EXTRA_DIST += \
+         certs/lms/bc_lms_sha256_h5_w4_root.der \
+         certs/lms/bc_lms_sha256_h10_w8_root.der \
+         certs/lms/bc_hss_L2_H5_W8_root.der \
+         certs/lms/bc_hss_L3_H5_W4_root.der \
+         certs/lms/bc_lms_chain_ca.der \
+         certs/lms/bc_lms_chain_leaf.der \
+         certs/lms/bc_lms_native_bc_root.der