[Lennonhaha]

Hi @Mehrn0ush,

As discussed in #1175, here are two 2.0 fixtures for family-only observations, where the NIST category is omitted rather than asserted.

• valid-cbom-family-only-mlkem-2.0.json — algorithmFamily: "ML-KEM", primitive: "kem", no parameter set
• valid-cbom-family-only-sm2-2.0.json — algorithmFamily: "SM2", primitive: "signature"

Per your guidance, neither fixture carries a nistQuantumSecurityLevel value, and neither uses a custom namespaced property, so they validate against the 2.0 schema alone. That keeps the distinction you drew: omission makes no claim, while 0 means none of the categories are met.

Both live under tools/src/test/resources/2.0 and use the valid- prefix, because AbstractJsonSchemaVerificationTest only loads resources whose names start with valid or invalid; a free-form name would be silently skipped.

The commit carries a DCO sign-off.

Local verification controls

Per your review request, here is exactly what was run, against which revision, and what it produced. The controls are local checks only — they are not committed as fixtures.

Schema revision: 2.0-dev at 76f185c45deb28c98b2555da9c752b9d43f50ecd, file schema/2.0/cyclonedx-2.0-bundled.schema.json ($id https://cyclonedx.org/schema/2.0/cyclonedx-2.0-bundled.schema.json, $schema draft 2020-12).

Validator: ajv 8.20.0 with ajv-formats 3.0.1, new Ajv2020({ strict: false, validateSchema: false, allErrors: true }). The companion schemas (cryptography-defs, behavior-taxonomy, spdx, jsf-0.82) are registered from schema/ under both https://cyclonedx.org/schema/<name> and https://cyclonedx.org/schema/2.0/<name>; validateSchema is disabled because the two draft-07 companions cannot be meta-validated by a 2020-12 instance.

Result (exit code 0, five cases):

case	expect	result
valid-cbom-family-only-mlkem-2.0.json as committed	valid	valid
valid-cbom-family-only-sm2-2.0.json as committed	valid	valid
control: algorithmFamily: "ML-KEM-NOT-A-FAMILY"	invalid	invalid
control: nistQuantumSecurityLevel: 7	invalid	invalid
control: nistQuantumSecurityLevel: 0	valid	valid

One caveat so the claim is not overstated: ajv-formats 3.0.1 does not provide iri-reference or idn-email, and Ajv reports those as ignored. No field in these two fixtures uses either format, and the structural assertions above are unaffected, but those two formats are not enforced by this local run.

Change since the first revision

The initial descriptions said the omission existed "because the assessment was not performed", which asserts an assessment status that omission cannot establish, and implies SM2 cannot be assessed. Both now use your suggested wording verbatim:

Algorithm family observed without a recorded parameter set or asserted NIST security strength category. Omission of nistQuantumSecurityLevel does not establish whether an assessment was performed.

Happy to adjust naming, placement or scope if you would prefer a different layout.

[Mehrn0ush]

This description explicitly asserts that an assessment was not performed. That conflicts with the PR description’s statement that these fixtures “say nothing about assessment status.”

An unperformed assessment is a legitimate example, but it is a narrower scenario than the neutral omission case discussed in #1175. To demonstrate that omission itself establishes neither a category nor assessment status, please remove the asserted reason for omission. Also, “without a NIST category” would be clearer as “without an asserted NIST category,” since the fixture does not establish that the algorithm lacks a category.

Suggested change

	"description": "Algorithm family observed without a parameter set and without a NIST category. nistQuantumSecurityLevel is omitted because the assessment was not performed; the omission is not a statement that no category is met.",
	"description": "Algorithm family observed without a recorded parameter set or asserted NIST security strength category. Omission of nistQuantumSecurityLevel does not establish whether an assessment was performed.",

[Lennonhaha]

You are right, and this is the same error the fixture pair exists to prevent: I wrote the omission as evidence of "not assessed", which is an inference the schema does not support. Omission records that no assertion was made — nothing about whether anyone looked.

I adopted your suggested wording verbatim in both fixtures:

Algorithm family observed without a recorded parameter set or asserted NIST security strength category. Omission of nistQuantumSecurityLevel does not establish whether an assessment was performed.

Pushed as 055d96d. I also added the local control commands, the schema revision (2.0-dev at 76f185c4) and their results to the PR description, including the caveat that ajv-formats does not provide iri-reference/idn-email.

[Mehrn0ush]

Same correction as the ML-KEM fixture. This example only needs to show that no category assertion was recorded. It shouldn’t state a reason for omission or imply SM2 can’t be assessed.

[Lennonhaha]

Same correction applied here: the SM2 fixture now uses the neutral wording rather than implying SM2 cannot be assessed or that no assessment happened.

Algorithm family observed without a recorded parameter set or asserted NIST security strength category. Omission of nistQuantumSecurityLevel does not establish whether an assessment was performed.

Pushed as 055d96d, together with the local control details in the PR description.

[Mehrn0ush]

Hi @Lennonhaha.
Thanks.
The two fixtures cover the omitted-category case for a family-only ML-KEM and SM2 observation, with no nistQuantumSecurityLevel and no namespaced property.

The controls from the PR description (bogus family, level 7, explicit 0) aren’t in the commit, so they’re local checks. Could you add the command or script and the schema revision to the PR description? That keeps them reproducible and separate from the committed fixtures.

I left inline comments on both description values: they state the assessment was not performed, but omission establishes nothing about that. The suggested wording describes only the recorded observation.

[Mehrn0ush]

Thanks, I reviewed 055d96d. Both fixture descriptions now correctly distinguish an omitted category from assessment status. This addresses my requested changes, and I approve the fixture changes.