Aspect
Section: 3.6 Mapping to serialization formats
Orientation relevance: both
CycloneDX and SPDX are the two common file formats these cryptography reports come in. Because our master list of facts (3.3) is deliberately kept format-neutral, we need clear translation tables showing how each fact is written in each format. This issue is about producing and maintaining those translations, and recording anywhere one format can't yet express something.
Example
Like a phrasebook that translates the same sentence into French and German, a mapping table shows that "algorithm = AES-256" is written one way inside a CycloneDX file and another way inside an SPDX file — so a profile written once can be honoured in either format without loss.
Objective
Decide how the abstract attribute model is mapped onto CycloneDX and SPDX, and how mapping
gaps are recorded and raised. Cross-cutting: other aspect threads should reference this issue
rather than re-debating mapping internally.
Background & links
Scoping document §3.6, and format independence in §2.6. References: CycloneDX v1.7 and
successors / ECMA-424 and the Cryptography Registry; SPDX 3.0.x and its planned cryptographic
metadata. Maps the model defined in 3.3.
Options under consideration
- Per-attribute mapping tables — maintained alongside the model, one row per attribute per
format. (Trade-off: granular; verbose.)
- One mapping document per format — narrative + tables. (Trade-off: readable; coarser.)
- Round-tripping — stated requirement (same information recoverable from either format) or
best-effort with documented exceptions.
Open questions
Dependencies
Depends on attribute model (3.3 #1). Cross-cutting — referenced by most aspect threads.
Coordinates with normalisation (3.7 #3).
Decision
Not yet decided.
Impact on the specification
Spec section "Mapping to CycloneDX and SPDX," plus the format-mapping annex.
Aspect
Section: 3.6 Mapping to serialization formats
Orientation relevance: both
CycloneDX and SPDX are the two common file formats these cryptography reports come in. Because our master list of facts (3.3) is deliberately kept format-neutral, we need clear translation tables showing how each fact is written in each format. This issue is about producing and maintaining those translations, and recording anywhere one format can't yet express something.
Example
Like a phrasebook that translates the same sentence into French and German, a mapping table shows that "algorithm = AES-256" is written one way inside a CycloneDX file and another way inside an SPDX file — so a profile written once can be honoured in either format without loss.
Objective
Decide how the abstract attribute model is mapped onto CycloneDX and SPDX, and how mapping
gaps are recorded and raised. Cross-cutting: other aspect threads should reference this issue
rather than re-debating mapping internally.
Background & links
Scoping document §3.6, and format independence in §2.6. References: CycloneDX v1.7 and
successors / ECMA-424 and the Cryptography Registry; SPDX 3.0.x and its planned cryptographic
metadata. Maps the model defined in 3.3.
Options under consideration
format. (Trade-off: granular; verbose.)
best-effort with documented exceptions.
Open questions
Dependencies
Depends on attribute model (3.3 #1). Cross-cutting — referenced by most aspect threads.
Coordinates with normalisation (3.7 #3).
Decision
Not yet decided.
Impact on the specification
Spec section "Mapping to CycloneDX and SPDX," plus the format-mapping annex.