Conformance

This section says what conformance means in this methodology. It covers what can be assessed, who may assert conformance, how an assertion is written down, and what an assertion does not cover. The Profile section sets out the rules of one example profile. This section describes the relation those rules take part in.

Requirement keywords

The keywords MUST, MUST NOT, SHOULD, SHOULD NOT and MAY are to be interpreted as described in BCP 14 (RFC 2119 and RFC 8174) when, and only when, they appear in capitals. The same keywords in lower case carry their ordinary English meaning and impose no requirement.

What can be assessed

Three different things can be assessed, and each is assessed against its own criteria. A claim that does not say which of the three it means is ambiguous. Saying that something "is conformant", without naming what was assessed, is not a conformance claim under this methodology.

The three depend on each other, and only in one direction. A verdict means something only if the tool that produced it conforms, and only if the profile it was measured against is well-formed. So a document assessed by a non-conforming tool has no established verdict. A verdict against a profile that is not well-formed establishes nothing either, because the rules the document was measured against were not valid rules in the first place.

1. A CBOM document conforming to a profile

A CBOM document conforms to a profile version when all of the following hold.

• The document's carrier format and version fall within the profile's declared acceptance range. See Versioning.
• Every product-level rule at MUST level is satisfied.
• Every declared interface satisfies every per-interface rule at MUST level.
• Every rule assessed as satisfied by a disclosure marker rather than a value is a rule the profile marks as withholdable.

Rules at SHOULD and MAY level are evaluated and reported, but they do not decide the verdict. An author who wants a requirement to decide the verdict states it at MUST level. Sometimes a consumer treats a SHOULD rule as binding anyway. That is a misreading of the profile, and the fix is for the author to raise the level if MUST was what they meant.

Verdict vocabulary

Refusal and non-conformance are reported separately and MUST NOT be merged. A refused document may be perfectly adequate. The profile is simply unable to say so, because it cannot express its rules against that version of the carrier format. Treating a refusal as a failure punishes a producer for the age of a format rather than for what the document discloses.

Effect of the disclosure states

An attribute with no value is assessed according to which of the four outcomes applies. The states are defined in the Profile section and are summarised here for their effect on a verdict.

So a document can conform while withholding something, and a consumer who reads only the verdict will not know that it did. This is why a conformance report states the disclosure state of every rule it assessed. A consumer who acts on the verdict alone is throwing away the part of the result most likely to matter commercially. The sharpest case is a public variant and a restricted variant of the same document. Both conform, and only one of them answers the question. See Confidentiality.

Conformance to more than one profile

A document evaluated against several profiles receives one verdict per profile, and no verdict implies anything about any other. There is one exception. Where one profile extends another, conformance to the derived profile does imply conformance to the base version it pins, because extension is monotonic. See the composition rules in Profile.

Scope of a verdict

A verdict applies to one revision of one document, assessed at a point in time. It does not extend to later revisions, to other documents describing the same product, or to the product itself. A product does not conform to a profile; a document describing it does.

2. A profile conforming to this methodology

A profile is well-formed under this methodology when it satisfies the following. These restate, as requirements, the outputs the procedure in Method produces.

C3, C6 and C7 are the three a review most often has to enforce. Each is easy to break while still producing a rules file that loads and runs without complaint. A profile that names a particular instance, for example, still evaluates documents perfectly well. It just evaluates them for one deployment rather than for the product.

The scope declaration

C11 asks for one object rather than a set of scattered fields. The subject, the relationship types and the accepted lifecycle stages together describe a single boundary, and Method step 2 decides all of them at once.

The last of the four is the one that changes verdicts. Without it, a document could report every interface at the intended stage and still conform. It would be describing cryptography the producer plans to build rather than cryptography that exists.

For a disclosure baseline that is acceptable, which is why the example baseline accepts all four stages. For a procurement or migration profile it is not, and the migration example accepts only the three stages that describe something real. A derived profile may narrow the set. It may not widen it, for the same reason it may not relax a rule.

Orientation, and why it is checked rather than taken on trust

Present state and declared capability sit in the same document, about the same interface, under names that differ by a single suffix. keyExchange is what an interface negotiates today. keyExchangeSupported is everything it could negotiate.

The naming conventions in Method keep the two names apart. They do not keep the two obligations apart. A profile that requires only the capability leaves a consumer holding a set of algorithms with no way to tell which one is in use, and the reading such a document invites is the wrong one.

C12 closes that by giving each orientation an obligation.

C12 is assessed against the resolved profile, so a rule inherited from a base can satisfy it. That is the normal case rather than a loophole. The example migration profile declares the three capability attributes itself, and takes their present-state counterparts from the baseline it extends. A profile that declared both and required capability alone would fail, and that is the case the requirement exists to catch.

Group rules, and why coverage is checked

A rule normally constrains one attribute of one interface. A group rule is different. It constrains a repeated group of entries, keyed by a controlled vocabulary, so that an interface gives one answer per key instead of one answer overall. The migration example uses this for capability. An interface states where it stands for each cryptographic purpose separately, because key agreement and identity proof migrate on different timetables, and a single status would have to report the worse of the two.

Two properties of a group rule are checked. Each of them has a failure mode that would otherwise slip through, because the rule looks entirely ordinary in the file and reports as passing.

The first is a group keyed to a vocabulary the profile never declares. Such a rule requires an entry for no keys at all, so every document satisfies it and the report shows it passing. C13 rejects the profile rather than issuing that verdict.

The second is a group whose coverage is set to in-scope while the vocabulary it is keyed to is larger. That lets a profile defer part of the problem and then never come back to it. A staged profile is meant to sequence how much detail an answer carries, not to remove the question. A purpose the profile has deferred still owes a status, and a blocker wherever that status is not available. Without that, a supplier can conform while behaving as though a whole class of cryptography does not exist, and each stage becomes a floor rather than a step towards something. C13 is what makes the difference checkable.

Identifier schemes

An inventory built from several suppliers has to work out which records describe the same thing. Identity cannot be settled in general, because some classes of asset have no agreed identifier at all. It can be settled one profile at a time, and that is the lever this methodology has. A profile names the form it requires for each class of asset its rules constrain, and a consumer then knows which naming scheme they are reading.

C14 does not check that a value really belongs to a registry. The checker does not hold the registry, so it would be guessing. What it does check is that the declaration and the rules agree in both directions. Every scheme a rule references must be declared, and every scheme declared must be referenced by some rule. A scheme that no rule applies drifts away from what the profile actually does, while continuing to read as authoritative. Which registry an algorithm name should come from is Q20, and that is unsettled. That a profile has to say which one it means is settled here.

C15 and C16: identifiers that can be cited

A rule identifier is local to the profile that declares it. A rule is therefore named as <profileTag>#<ruleId>, and three profiles in one family may each declare an I1 of their own. This moves the uniqueness requirement off the rule identifiers, which no author can coordinate across a whole family, and onto the tag, which an author picks once. C15 is the check that the tag is unique. Without it, a citation could resolve to two different rules and a stored conformance claim would stop meaning anything. With it, a base profile can add a rule without first asking what its derived profiles have already used.

C16 fixes what the letter means, rather than leaving it to the author. P means the rule is evaluated once per product, I once per declared interface, and G once per entry in a group. The tag already says which profile a rule belongs to, so the letter is free to carry the thing a reader actually wants to know. C16 does not require the numbers to run without gaps. A released identifier is never reused, so gaps are correct, and a checker that demanded a contiguous sequence would forbid exactly what that rule exists to allow. See decision 0011.

The third artifact: a claim

Two of the conformance targets are checked by someone who holds the inputs: a document against a profile, and a profile against the methodology. The claim is the third artifact, and the only one read by someone who does not hold the inputs. Typically a buyer, months later, in a different organisation.

A claim is a machine-readable document. It is bound to one CBOM by digest. It lists every profile that was evaluated, each with its own verdict and its whole pinned chain. And it carries the disclosure states and the non-assertions inside itself, rather than pointing at them somewhere else.

The non-assertions matter most here. Everything the table at the end of this page says about what a verdict does not establish is repeated inside every claim. The person reading a claim will not have read this page, and the word “conforms” invites more inference than it can carry.

A claim can be re-checked. Running --verify-claim confirms the digest and re-runs each profile the claim names. What it cannot establish is that the disclosed values are true, and no version of it ever will: a producer who misstates a protocol version produces a claim that verifies perfectly. See decision 0015, and 0016 for what an SPDX-only claim may assert.

C17: rules that cannot fail

A rule that cannot fail is worse than a missing rule. The report says it passed, and a reader has no way to tell the difference. There are three ways to write one, and until recently all three survived review.

• Give the rule no constraint at all.
• Misspell the constraint key, so the evaluator recognises nothing and reports ok against every value.
• Point the rule at a vocabulary that does not exist. This is the mirror image of the second: it fails every value, while saying only that the value was not accepted.

C13 already rejected the third case for group keys. C17 covers the rest, and the validator refuses such a profile rather than issuing a verdict against it.

This is C13's principle applied more widely: a profile must be able to be wrong. It is written as a requirement rather than left to review because none of the three defects is visible when you read the file. Each one produces a rule that looks entirely ordinary.

C1 to C7 and C11 to C17 are checked mechanically by check_profile.py, which takes a rules file and reports on each requirement in turn. C8 to C10 are checked where the profile declares the material, and are reported as warnings that do not affect the result unless --strict is given.

All three example profiles pass: the entry profile of the interface family, the disclosure baseline and the migration profile. The test suite also carries one deliberately defective profile for each MUST requirement, so that the checks themselves are tested.

The tool does not replace review. C3 in particular is enforced through structural proxies, so a rule that names a specific instance in some way the checker does not model would still pass.

3. An evaluation tool conforming to this methodology

Two tools given the same document, the same profile, and the same resolution of any extended base should return the same verdict. The requirements below are what that expectation rests on.

The reference validator signals T5 through its exit code: 0 for conforms, 1 for does not conform, 2 for a usage error, 3 for a profile error such as a relaxing override, and 4 for a refusal.

The fourth code exists because of T1. A caller that cannot tell a refusal from a failure will reject a producer for the age of a carrier format.

Until August 2026 the validator printed DOES NOT CONFORM and exited 1 on a refusal, merging exactly what this section says must not be merged. The test suite asserted that exit code, so the defect was pinned in place rather than caught.

What the methodology requires is that the distinction reaches the caller. The particular codes are an implementation choice, and another tool may signal it differently.

This site runs two tools, which makes the expectation above testable rather than aspirational. validate_cbom.py is the reference implementation. The Demo page is a second one: a static page cannot run Python, so the evaluation is written again in JavaScript.

The demo used to carry its own transcription of the rules as well, and the page asserted that its results matched the reference tool while nothing checked either half. The rules are now fetched from the published rules file, so there is a single statement of them. The logic is still a second implementation, so tests/check-demo.py runs the page's own functions over the four example documents. It requires the same verdict, the same outcome for every rule, the same disclosure state for every value, and the same carrier band.

The two had diverged once before this check existed. A published page that quietly disagrees with the specification is worse than no page at all, and the sentence this section opens with, two tools and one verdict, was being asserted with nothing behind it. See decision 0018.

Making and recording a claim

A conformance claim is a statement by an identified party that a named document revision was assessed against a named profile version and produced a stated verdict.

What a claim cites

A claim names three things: the profile and its version, the carrier format and its version, and the content revision of the document that was assessed. A claim missing any of the three cannot be reproduced, and a claim that cannot be reproduced cannot be audited. Where a derived profile was used, the claim also names the base and the version it pins.

Conforms to:
  pkic.example.pqc-migration v0.6
    extending pkic.example.interface-disclosure v0.7
Carrier: CycloneDX 1.7
Content revision: 3
Assessed by: Example Ltd (self-declared)
Assessed on: 2026-08-09
Tool: validate_cbom.py 0.2

Who may claim

A claim is made by the party that performed the evaluation, and identifies that party. A producer evaluating its own document makes a self-declared claim, which is permitted and is labelled as such. A claim made by a party other than the producer is an attested claim, and carries whatever additional weight the relying party assigns to the attesting party.

Validity over time

A claim is fixed to the revision it assessed and does not roll forward. A new content revision needs a new evaluation. So does a new profile version, and where that version tightened a rule, a document that conformed before may no longer conform. The changelog is what tells a producer whether re-evaluation is likely to be needed, and that is why the methodology asks for every change to be classified.

What a conformance verdict does not assert

The verdict is a statement about disclosure. It is worth being explicit about the claims it is likely to be mistaken for.

The last two rows are the ones most likely to cause trouble in procurement. Both allow a document to conform while leaving out something the buyer assumed was covered. The remedy is in the profile author's hands: write product rules strong enough that the omission fails the evaluation. This is a drafting question, and the conformance semantics do not need to change to deal with it.