Support RFC 9802 LMS and XMSS in X.509 certificate and CSR generation#21
Closed
Frauschi wants to merge 1 commit into
Closed
Support RFC 9802 LMS and XMSS in X.509 certificate and CSR generation#21Frauschi wants to merge 1 commit into
Frauschi wants to merge 1 commit into
Conversation
Frauschi
commented
Jun 2, 2026
Frauschi
commented
Jun 2, 2026
| certs/xmss/bc_xmssmt_sha2_40_8_256_root.der \ | ||
| certs/xmss/bc_xmss_chain_ca.der \ | ||
| certs/xmss/bc_xmss_chain_leaf.der | ||
| # No committed XMSS X.509 fixtures: there is no RFC 9802-aligned third-party |
Owner
Author
There was a problem hiding this comment.
can we simply remove the file and the directory instead?
Owner
Author
There was a problem hiding this comment.
Done — removed certs/xmss/include.am entirely and dropped its include certs/xmss/include.am line from certs/include.am, so the certs/xmss/ directory is gone rather than kept as an empty file.
Note this was folded into the rebase onto the updated master: upstream had moved the LMS/XMSS tests out of tests/api.c into tests/api/test_lms_xmss.c, so I re-homed all the generation test work there (api.c is now unchanged from upstream) and resolved the conflict that way. Force-pushed the rebased branch.
Generated by Claude Code
0aab291 to
f14a143
Compare
Extend wc_MakeCert_ex/wc_SignCert_ex/wc_MakeCertReq_ex to issue HSS/LMS and
XMSS/XMSS^MT certificates and PKCS#10 requests, building on the existing
RFC 9802 verification support. New LMS_TYPE/XMSS_TYPE/XMSSMT_TYPE selectors,
wc_{Lms,Xmss}Key_PublicKeyToDer SPKI encoders, runtime signature-buffer
sizing, and sigType/key consistency checks. Generation is ASN.1-template
only, matching where the verification path lives.
Tests generate self-signed roots, CSRs and a CA->ECC-leaf chain in-process
and verify them, replacing the patched Bouncy Castle fixtures (only the stock
RFC 9802-aligned LMS interop anchor is kept).
https://claude.ai/code/session_01RDkoNViK5aNkUAJqnuL8Y5
f14a143 to
b663393
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
Builds on the existing RFC 9802 LMS/XMSS X.509 verification support by wiring HSS/LMS and XMSS/XMSS^MT keys into the certificate and PKCS#10 certificate-request generation API. These stateful hash-based schemes follow the same "sign the message directly, no pre-hash" pattern already used for Falcon / ML-DSA / SLH-DSA.
CSR support is included (per design discussion): cert signing and CSR proof-of-possession share the same
MakeSignature()dispatch, and there's no reason to special-case CSRs out. The only caveat — each cert and each CSR consumes one of the key's finite one-time signatures — is inherent to the scheme and documented at the API surface.Public API
CertTypeselectorsLMS_TYPE,XMSS_TYPE,XMSSMT_TYPEaccepted bywc_MakeCert_ex,wc_SignCert_exandwc_MakeCertReq_ex.cert_enumsvaluesLMS_KEY,XMSS_KEY,XMSSMT_KEY.wc_LmsKey_PublicKeyToDer/wc_XmssKey_PublicKeyToDerencoders that emit the RFC 9802 SubjectPublicKeyInfo via the existingSetAsymKeyDerPublichelper and the already-registeredHSS_LMSk/XMSSk/XMSSMTkkey OIDs.cert->sigTypetoCTC_HSS_LMS/CTC_XMSS/CTC_XMSSMT.Implementation
LmsKey*/XmssKey*throughEncodePublicKey,MakeAnyCert,MakeCertReq,MakeSignatureandSignCert(ASN.1 template path), mirroring the existing PQ-key plumbing.SignCertsizes the signature buffer at runtime fromwc_LmsKey_GetSigLen/wc_XmssKey_GetSigLen, since LMS/XMSS signatures are parameter-dependent and can exceedMAX_ENCODED_SIG_SZ. InWOLFSSL_NO_MALLOCbuilds (fixed-size buffer) an oversized signature fails cleanly withBUFFER_Erather than overflowing.SignCertvalidates thatsigTypematches the key (LMS →CTC_HSS_LMS; XMSS →CTC_XMSS/CTC_XMSSMTperis_xmssmt), and theXMSS_TYPE/XMSSMT_TYPEselector is validated against the key's tree variant — so a mismatch returns an error instead of silently emitting a malformed certificate.LmsKey/XmssKeyinasn_public.h(guarded typedefs inwc_lms.h/wc_xmss.h) so the shared signatures compile regardless of feature macros.WC_ENABLE_ASYM_KEY_EXPORT/IMPORTfor non-verify-only LMS/XMSS builds so the SPKI encoder is compiled.MakeAnyCert/MakeCertReqemit a clear diagnostic andALGO_ID_Eif handed such a key.Tests
test_rfc9802_lms_x509_gen/test_rfc9802_xmss_x509_gengenerate a self-signed root CA and a PKCS#10 CSR, then verify the cert viawolfSSL_CertManagerVerifyBufferand the CSR proof-of-possession viawc_ParseCert. Coverage includes single-level LMS, multi-level HSS (L2), single-tree XMSS, and XMSS^MT, plus negative cases for sigType/keyType and selector mismatches.Notes / scope
WOLFSSL_ASN_ORIGINAL(non-template), and verify-only LMS/XMSS builds; the API test suite passes with 0 failures, andtestwolfcryptpasses.https://claude.ai/code/session_01RDkoNViK5aNkUAJqnuL8Y5
Generated by Claude Code