CycloneDX Cryptography Registry

◆ practitionerThe same cryptographic mechanism gets a different name from every angle you look at it — CKM_ECDSA_SHA256 to an HSM, OID 1.2.840.10045.4.3.2 to a certificate, ES256 to a JWT, code point 0x0403 to TLS 1.3. A CBOM (or any inventory) built from several discovery tools inherits all of these inconsistent names — and nothing lines up until you normalize them.

● standardCycloneDX v1.7 answers this with the Cryptography Registry: one versioned, machine-readable list of canonical algorithm-family and elliptic-curve names, each backed by its standardization reference (RFC, FIPS, IEEE, ISO).

● standard96 algorithm families across 14 primitive types — signatures, key encapsulation, key agreement, block and stream ciphers, authenticated encryption, MACs, hashes, XOFs, KDFs, key-wrap and DRBGs — each with standardization references and naming-pattern templates for its parameterized variants (e.g. key length, hash choice).

● standard246 elliptic curves across 15 standardization categories (NIST, SECG, Brainpool, ANSSI, BLS, GOST, X9.62/X9.63 and more) — each entry carries its OID, algebraic form (Weierstrass, Edwards, Montgomery), and cross-referenced aliases, so P-256, secp256r1 and prime256v1 are recorded as the same curve.

● standardML-KEM, ML-DSA, SLH-DSA, XMSS and LMS are registered algorithm families alongside RSA, ECDSA and AES — not a separate or bolted-on list. For a PQC-readiness review, that means one place to check whether a mechanism a scanner found is quantum-safe, quantum-vulnerable, or a stateful hash-based signature that needs its own state-management scrutiny.

◆ practitionerPQC makes normalization harder, not easier: ML-DSA registers one OID per parameter set (RFC 9881's id-ml-dsa-44/65/87), so a single family fans out into several distinct identifiers a tool must still resolve back to “ML-DSA”.

● standardThe registry ships as its own versioned JSON + JSON Schema, decoupled from the CycloneDX specification release cycle — it can add a new algorithm family without waiting for the next CycloneDX version.

◆ practitionerIt is explicitly designed for use outside CBOM or CycloneDX entirely: an SPDX-based scanner, a homegrown inventory format, or a compliance dashboard can all adopt the same canonical names — CBOM is simply CycloneDX's own consumer of it.

◆ practitionerEvery discovery source you already run — HSM query, certificate scan, source-code scanner, network capture — hands you a mechanism name in its own notation. The registry is the lookup table that resolves each one to a single canonical family or curve before it goes into your inventory, which is what makes a policy-as-code check (quantum-safe / quantum-vulnerable / unknown) match reliably across sources.