Aspect
Section: 3.10 Forward-looking and roadmap information
Orientation relevance: migration
Some profiles need to capture not only the cryptography a product uses today, but what a vendor plans to support in future — which matters a lot for the shift to quantum-safe cryptography. This issue is about whether and how that "future intentions" information is recorded, and how to keep it clearly separate from present-day facts so nobody is misled.
Example
A car's spec sheet says what the car has now; the manufacturer's roadmap says "we'll add this feature next year." Mixing the two would mislead a buyer. In the same way, "this product supports quantum-safe encryption today" must never be confused with "we plan to support it in 2027" — this issue decides how to record the plan without blurring it into the present.
Objective
Decide how migration-oriented profiles express capability and intent without confusing current
state with future commitment.
Background & links
Scoping document §3.10, and the inventory-vs-migration distinction in §2.5. Real deployments
show "capable of" diverging from "configured and active" — the methodology must keep these
distinct.
Options under consideration
- Separate linked artifact — the CBOM records current state only; roadmap/commitments live
in a complementary, clearly separated artifact. (Trade-off: clean integrity of the CBOM;
two artifacts to manage.)
- Flagged forward-looking fields — roadmap data carried inside migration profiles,
explicitly marked as forward-looking. (Trade-off: single artifact; risk of conflation if
flagging is weak.)
Open questions
Dependencies
Depends on orientation declaration (3.1 #4) and attribute model (3.3 #1).
Decision
Not yet decided.
Impact on the specification
Spec section "Forward-looking information for migration profiles."
Aspect
Section: 3.10 Forward-looking and roadmap information
Orientation relevance: migration
Some profiles need to capture not only the cryptography a product uses today, but what a vendor plans to support in future — which matters a lot for the shift to quantum-safe cryptography. This issue is about whether and how that "future intentions" information is recorded, and how to keep it clearly separate from present-day facts so nobody is misled.
Example
A car's spec sheet says what the car has now; the manufacturer's roadmap says "we'll add this feature next year." Mixing the two would mislead a buyer. In the same way, "this product supports quantum-safe encryption today" must never be confused with "we plan to support it in 2027" — this issue decides how to record the plan without blurring it into the present.
Objective
Decide how migration-oriented profiles express capability and intent without confusing current
state with future commitment.
Background & links
Scoping document §3.10, and the inventory-vs-migration distinction in §2.5. Real deployments
show "capable of" diverging from "configured and active" — the methodology must keep these
distinct.
Options under consideration
in a complementary, clearly separated artifact. (Trade-off: clean integrity of the CBOM;
two artifacts to manage.)
explicitly marked as forward-looking. (Trade-off: single artifact; risk of conflation if
flagging is weak.)
Open questions
Dependencies
Depends on orientation declaration (3.1 #4) and attribute model (3.3 #1).
Decision
Not yet decided.
Impact on the specification
Spec section "Forward-looking information for migration profiles."