Skip to content

[FEATURE]: CBOM - agility features #892

Closed

Description

@bhess

Cryptographic Agility features

Motivation

Organizations preparing for PQC migration need to understand how agile their cryptography is. The Agility Plane captures properties that describe how easily cryptographic assets can be reconfigured, rotated, renewed, and migrated.

Without this metadata, it is difficult to answer questions like: Can this algorithm be swapped at runtime? Are keys auto-rotated? Is certificate renewal automated? Is this a vendor black box or changeable in-house? Is there a PQC transition plan?

Agility Plane Dimensions

Dimension Description Example values
Configuration source How the crypto config was determined admin-configured, default-config, negotiated, hardcoded
Change mechanism How a crypto change is applied hot-swap/runtime, restart, software-update, hardware-dependent, not-possible
Rotation & renewal How keys/certs are rotated or renewed manual, automatic, ACME, on-demand, not-supported
Ownership Who controls the implementation inhouse, vendor, open-source
Roadmap Migration planning toward PQC Transition plan, target algorithms, timeline

Discussion: Schema Integration

These dimensions could be integrated as optional fields in the cryptography model. Some natural attachment points:

  • Configuration source & change mechanism — could live on cryptoProperties (cross-cutting) or on individual asset-type properties (e.g., algorithmProperties). The key question is whether these apply uniformly across all asset types or are more meaningful for specific ones.
  • Rotation & renewal — naturally fits alongside existing lifecycle fields on certificateProperties and relatedCryptoMaterialProperties.
  • Ownership — could be a new field on cryptoProperties, but may overlap with existing component-level metadata (supplier, author).
  • Roadmap / PQC transition — What level of structure is appropriate?

There might be additional agility dimensions to be considered.

Activity

  1. added this to the 2.0 milestone on Mar 26, 2026
  2. bhess commented on Apr 2, 2026

    @bhess
    ContributorAuthor

    To further address 'Rotation & renewal', I suggest adding these attributes as properties within certificateProperties and relatedCryptoMaterialProperties:

    • manual (Standard human-driven action)
    • ceremony / quorum (High-assurance, multi-party offline rotation)
    • on-demand (Triggered via API/script, not scheduled)
    • automatic (System handles it natively, e.g., cron-based)
    • delegated / provider-managed (Offloaded to KMS, Cloud Provider, etc.)
    • protocol-driven (with a sub-field specifying ACME, SCEP, EST, CMP, etc.)
    • ephemeral (Rotated/renewed continuously/per-session)
    • not-supported (Cannot be changed)
  3. stevespringett commented on Apr 30, 2026

    @stevespringett
    Member
    • The "ownership" will likely tie in nicely with the new actor/role model being developed for 2.0.
    • The "roadmap" may be covered by the mitigation support in the "risk" schema.

    Will need to investigate both approaches to ensure that they will meet the intended use cases described in this ticket. The "ownership" feature is currently further along.

  4. jkowalleck commented on Jul 27, 2026

    @jkowalleck
    Member

    RFC notice sent on July 23, 2026

    Public RFC period ends August 20, 2026

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions