Repository navigation
[3.3] Format-independent attribute model #1
Description
Activity
Two points from implementing a multi-surface CBOM discovery tool, offered as input to the master attribute list.
- The attribute model should make explicit which attributes are identity-bearing. Because the same asset is discovered on different surfaces (on the wire, in a file, in a binary), we needed a defined notion of when two findings are "the same asset." Two cases turned out to be load-bearing in non-obvious ways:
- Primitive / intended use is identity-bearing at the algorithm level. An RSA algorithm entry used for signatures and one used for key transport should not collapse into a single entry, they have different migration targets (ML-DSA vs ML-KEM) and often different remediation owners. So primitive (signature / key-encapsulation / key-agreement / ...) has to be part of an algorithm's identity, not just a descriptive tag. (Where a certificate's X.509 KeyUsage disambiguates the signature-vs-key-transport role we use it; where KeyUsage is absent the role is genuinely ambiguous, and how to represent that honestly, rather than fall back to a default is really an obligation-level question, [3.4] Obligation levels & conformance semantics #6.)
- Some attributes are deliberately name-agnostic. Conversely, a curve-based key establishment named ECDH-P256 by one tool and observed as a bare P-256 curve parameter by another is the same asset. Identity there keys off the curve + a class marker, not the name.
Suggestion: the master list could annotate each attribute with whether it participates in asset identity, so profiles and tools deduplicate consistently rather than each inventing their own rule.
- Caution on including verdict-like facts (e.g. "is it out of date") in the neutral list. The body lists "is it out of date" as a candidate fact. In our experience "out of date / deprecated" is not a stable, format-independent fact, it is a function of a raw fact and a policy:
deprecated? = f( raw fact: algorithm, key length, NIST quantum security category, ... ,
policy: jurisdiction + effective date )NIST IR 8547's draft 2030/2035 timeline, BSI TR-02102, and CNSA 2.0's allowlist can give different answers for the same key on the same day. If "deprecated" lives in the neutral attribute list, the same CBOM has to be re-inventoried to be re-assessed for another mandate or a later date.
We keep the boundary as strict as we can: the attribute list carries jurisdiction-and-date-independent raw facts (algorithm family, key length, parameter set, curve, primitive, NIST PQC security category). Where we do store a policy-derived datum, a static NIST IR 8547 transition-table label (e.g. the "deprecate-by-2030" bucket) - we treat it explicitly as a citable label, not a live verdict: whether an asset actually counts as deprecated as of a given date and jurisdiction is computed by a separate, swappable policy layer (mapping naturally onto the obligation/conformance (#6), roadmap (#10), and regulatory-alignment (#12) aspects). That separation keeps one inventory re-scorable across mandates and over time without rescanning.
Suggestion: define the master list as raw facts only, and route time/jurisdiction-dependent judgements to the obligation and regulatory aspects.
Aspect
Section: 3.3 Format-independent attribute model
Orientation relevance: both
This is the master list of every fact a profile is allowed to ask for, things like which
algorithm, how long is the key, and is it out of date. Every profile picks the items it
needs from this one shared list. Agreeing the list once, in a neutral way, is what guarantees
that two profiles asking for "the algorithm" mean the same thing. It is the foundation the other
twelve aspects build on, which is why it goes first.
Example
Think of a restaurant's master ingredient list. Individual dishes each use a subset of it, but
"tomato" means the same tomato in every dish. Here the "ingredients" are cryptography facts, and
this issue decides what belongs on the master list, how much detail each entry carries, and how
to keep that list independent of any single file format so it works with both CycloneDX and SPDX.
Objective
Define the shared abstract model of cryptographic attributes that profiles select from and
constrain — the foundation that makes the whole methodology format-independent. Settle this
first; most other aspects depend on it.
Background & links
Scoping document §3.3, and the format-independence principle in §2.6. Inputs to review:
the CycloneDX cryptographic asset model and Cryptography Registry concepts (ECMA-424,
CycloneDX v1.7); SPDX 3.0.x cryptographic coverage as it matures. The model must map cleanly
onto both (see 3.6).
Options under consideration
and SPDX map onto. (Trade-off: most neutral; more to maintain.)
asset model and Registry. (Trade-off: faster; risk of format bias.)
that profiles cite, or inside the methodology document.
Open questions
Dependencies
Blocks obligations (3.4 #6), conformance (3.5 #7), format mapping (3.6 #2),
normalisation (3.7 #3), layering (3.8 #8), extensibility (3.9 #9). No upstream
blocker.
Decision
Not yet decided.
Impact on the specification
Spec section "The format-independent attribute model" (the core normative chapter).