Add ShangMi (SM2/SM3/SM4/SM9) algorithm families

[Mehrn0ush]

Fixes #811

Adds SM2/SM3/SM4/SM9 algorithm families to the CycloneDX cryptography registry and updates algorithmFamiliesEnum accordingly.

Note: some official ShangMi specification mirrors appear region-blocked or unreliable from multiple locations.
To avoid fragile links in the registry, this PR relies on globally accessible references (RFC Editor + ISO)

[Mehrn0ush]

Hi @bhess — if you have time, would you mind taking a look at this one as well?

This adds ShangMi (SM2/SM3/SM4/SM9) families and updates the schema enum.
I used RFC/ISO references where the official mirrors weren’t reliably accessible.

Thanks a lot — always appreciate your feedback.

[stevespringett]

cc: @bhess

[bhess]

Thanks @Mehrn0ush for the additions! See the comments inline.

[bhess]

the "ae" modes seem to be missing (e.g., CCM, GCM..)

[Mehrn0ush]

Thank you for the note — you’re absolutely right. I’ve added an explicit ae variant for SM4 covering GCM and CCM (pattern: SM4-(GCM|CCM)[-{tagLength}][-{ivLength}]), and kept the existing block-mode variant (ECB/CBC/CFB/OFB/CTR/XTS) under block-cipher. This mirrors the registry’s existing separation of block modes vs authenticated-encryption modes.

[bhess]

SM9 seems to be not specified in RFC8998. See https://en.wikipedia.org/wiki/SM9_(cryptography_standard) for the references.

[Mehrn0ush]

Thanks for pointing that out. You’re correct — SM9 is not specified in RFC8998. I updated the SM9 standard reference accordingly to GM/T0044.1-2016 and switched the URL to the corresponding GM/T document.

[bhess]

rather than a single "other" primitive, it might be worth splitting this up to different variants.
I didn't look at the standard in the detail, but see https://en.wikipedia.org/wiki/SM9_(cryptography_standard), there are different primitives:

• signature
• keyagree/wrap
• kem

[Mehrn0ush]

Appreciate the suggestion — I replaced that entry using primitive other with multiple variants split by primitive to reflect the distinct SM9 functionalities:

signature via SM9-(SIG|SIGNATURE)

key-agree via SM9-(KEX|KEYEXCHANGE|KEY-EXCHANGE|KEYAGREE|KEYAGREEMENT|KEY-AGREE|KEY-AGREEMENT)

kem via SM9-(KEM|KEYENCAPSULATION|KEY-ENCAPSULATION)

pke via SM9-(ENC|ENCRYPTION|PKE|PUBLICKEY-ENCRYPTION|PUBLIC-KEY-ENCRYPTION)

If you’d prefer limiting SM9 strictly to signature / key agreement / KEM (as commonly summarized), I’m happy to drop the pke variant — I included it for completeness in case implementations label SM9 encryption explicitly.

[Mehrn0ush]

One question on SM2 naming conventions for the registry: I currently model SM2 as SM2-256 (and ...-256 for ENC/KEX) to be explicit about the common curve size. Would you prefer making the suffix optional (SM2[-256]) to align with the registry’s broader matching style, or keeping it strict as SM2-256? I can adjust either way — just want to follow the convention you think is best for downstream matching.
And,
Related detail: for SM4 placeholders I followed the existing conventions in cryptography-defs.json, where block cipher modes use {ivlen}, while ae modes use {ivLength} together with {tagLength} (consistent with how AES-GCM/CCM are expressed in the registry). If you’d rather normalize these placeholders to a single naming form across the file, I’m happy to align SM4 accordingly.

Thanks again @bhess