Cryptographic inventory & algorithm-agility seams

NCCoE SP 1800-38B shape: every algorithm this product deploys, what it protects, its harvest-now-decrypt-later (HNDL) exposure verdict, and the SWAP PATH — the named code seam a replacement lands through. This file is the deliverable the Enterprise Line’s PQC milestone (v1.28.62) pins: the reg_watch::pqc_inventory_seam_deliverable test asserts the inventory AND the two agility seams below stay present and truthful.

Posture: documented measurement, not certification. No PQC primitive is deployed anywhere in this codebase — this document is the seam map that makes the landing a config+key exercise, not a protocol rewrite. The horizon we plan against: NIST IR 8547 / OMB M-26-15 / CNSA 2.0 (key-establishment migration complete by 2030-12-31; signatures 2031). Sources: https://csrc.nist.gov/pubs/ir/8547/final · https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.1800-38B.pdf

Algorithm inventory

HNDL exposure verdicts (the honest summary)

• Nothing in brain-server is long-lived confidential ciphertext under a quantum-vulnerable primitive. The only ciphertext at rest is AES-256-GCM (backups + standby chunks), whose 256-bit keys retain a ~128-bit post-quantum security margin under Grover — the classical symmetric recommendation CNSA 2.0 lands on. The verdict is KEEP.
• The quantum-exposed class here is signatures, and the exposure is forgery-later, not decrypt-later. Recorded Ed25519 signatures (audit-linked UMP records, signed cards, parcels, standby manifests, provenance marks) must remain unforgeable for the evidence’s retention life. The mitigation is algorithm agility (below), deployed BEFORE any PQC-forgery capability exists — exactly what this seam map is for.
• The classical-crypto ceiling is stated, not hidden: until a PQC stack lands (JWT ML-DSA needs the IdP first — see the procedure), every signature in this system is classical. That is the Enterprise audit report’s printed ceiling; this file is how it gets closed.

Algorithm-agility seams

JWT: the ML-DSA landing procedure (FIPS 204)

src/auth/jwt.rs is the single JWT verification entry point, and its algorithm dispatch is already enum-isolated: decode_header reads the JOSE alg BEFORE any key material is touched, the whitelist (ALLOWED_ALGS) rejects everything unlisted, and Validation::new is pinned per-token to the header’s alg (no library-default HMAC confusion). Landing ML-DSA is therefore:

1. Key material: ML-DSA public keys arrive as JWK (kty per the IETF JOSE PQC drafts) in the IdP’s JWKS, or as files in BRAIN_JWT_KEY_DIR (auth/jwks.rs — add the ML-DSA loader beside the RSA/EC/Ed25519 ones). Key-dir + config work; no schema, no wire change.
2. Whitelist: add the algorithm to ALLOWED_ALGS in auth/jwt.rs — the ONE gate every token passes. The OWASP posture is unchanged: only the documented IdP’s algorithm joins; HS*/none stay forbidden.
3. Verifier: when jsonwebtoken (the repo pins v11) gains the algorithm, this is a one-line Algorithm variant. If it does not, the two-phase design already gives the seam: decode_header’s alg field routes ML-DSA tokens to a dedicated verify fn (the same whitelist-then-key order, ML-DSA verification library beside the crate). The OWASP cheat-sheet contract (whitelist before key lookup, per-token Validation, jti required) is re-asserted by the existing test matrix, which is written against the seam, not the library.
4. Rotation: JWKS kid rotation is live machinery (1–3 keys during rotation). Dual-algorithm transition = serve RS256 + ML-DSA kids in parallel, retire RS256 kids after the IdP flips — no downtime, no token invalidation beyond the normal expiry.

The honest dependency: an IdP must issue ML-DSA tokens first. This procedure is the receiver-side readiness, recorded before it is needed.

UMP signatures: the algorithm version-prefix rule

Every UMP-family signature names its signer as a did:key:z… string whose bytes are multicodec varint || raw public key (ump_integrity:: did_key_from_ed25519 prefixes 0xed 0x01, the registered Ed25519-pubkey code; verifying_key_from_did REFUSES any other codec). The multicodec table IS the algorithm version prefix:

• A future ML-DSA/SLH-DSA UMP signer lands as a NEW registered multicodec code with its own prefix bytes. did:key strings then self-describe their algorithm — old verifiers reject the unknown prefix (fail closed, the exact behavior verifying_key_from_did ships today), new verifiers dispatch on the prefix. No out-of-band algorithm negotiation, no ambiguity about which key made which signature.
• Records and manifests stay byte-compatible: the integrity/signed_by fields already carry the did string verbatim; the signature algorithm is a property of the DID, not a new field.
• The dual-sign transition for long-lived evidence: re-sign under BOTH the Ed25519 did and the PQC did during the migration window (parcels and standby manifests carry the manifest JSON, so a second signature block is additive); verify accepts either during the window, only the PQC did after cutover.
• Parcel manifests additionally carry the integer version field (PARCEL_VERSION, enforced on import) — a format-level escape hatch that stays reserved for changes the DID prefix cannot express.

What this file does NOT claim

No PQC algorithm is deployed. No hybrid signature is deployed. The 2030 horizon is a planning input, not a deadline this codebase currently meets for signatures; the inventory above is the measured starting point it will be measured against.