



Internet Engineering Task Force                              J. Dev, Ed.
Internet-Draft                                                   Comcast
Intended status: Informational                             20 April 2026
Expires: 22 October 2026


Output Schema Based on Cryptographic Bill of Materials (CBoM) for Post-
                       Quantum Cryptography Usage
                   draft-dev-xipher-cbom-extension-00

Abstract

   This document defines an output schema for inventorying cryptographic
   assets based on Cryptographic Bill of Materials (CBoM).  It
   highlights key differences between an inventoring schema and CBoM,
   identifies gaps, and proposes a unified schema that can leverage
   existing CycloneDX parameters to create a usable cryptographic asset
   inventory.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 22 October 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Dev                      Expires 22 October 2026                [Page 1]

Internet-Draft             PQC CBoM Extension                 April 2026


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Cryptographic Asset Inventory (CAI) . . . . . . . . . . . . .   3
   3.  Components of a CAI . . . . . . . . . . . . . . . . . . . . .   4
   4.  Differences between CBoM and a Cryptographic Asset Inventory
           (CAI) . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Data Structure for CAI  . . . . . . . . . . . . . . . . . . .   7
   6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   A CBoM or Cryptographic Bill of Materials (CBoM) is an extension of
   the Software Bill of Materials (SBoM).  SBoM are typically used to
   describe various components of a software, which helps assess
   vulnerabilities and provenance of such components.  A CBoM is an
   added representation on top of SBoM that further describes
   cryptographic components in the software.  For example, a CBoM can
   describe the cryptographic algorithms, key sizes, modes of operation,
   and other relevant details of the cryptographic components used in
   the software.  This additional information helps organizations better
   understand what cryptographic algorithms exist, where they are used,
   and make informed decisions about their deployment (e.g., whether to
   deprecate algorithms or not, etc.).  For the purpose of this
   document, we follow IBM's well known CBoM schema [cbom].  As of 2025,
   the latest version of CBoM schema that is part of the well known SBoM
   standard CycloneDX v1.7 is the following:








Dev                      Expires 22 October 2026                [Page 2]

Internet-Draft             PQC CBoM Extension                 April 2026


   <CODE BEGINS> file "cbom.json"
             component:
               type: library
               name: example-component
               version: 1.0.0
               cryptographicProperties:
                 - algorithm
                   - additional algorithm properties
                 - certificate
                   - additional certificate properties
                 - protocol
                   - additional protocol properties
                 - related cryptomaterial
                   - additional related cryptomaterial properties
               other properties...
   <CODE ENDS>

    Figure 1: Pseudo representation of CBoM Available in CycloneDX v1.7

   Such CBoM are currently generated at a software component level,
   either through static or dynamic analysis.  In practice, this can
   look like a mix of automated tools and manual processes to generate
   CBoM for software components.

2.  Cryptographic Asset Inventory (CAI)

   A Cryptographic Asset Inventory (CAI) is an organizational level
   inventory of all cryptographic assets used within an organization.
   This includes hardware, software, and services that utilize
   cryptographic algorithms for security purposes.  The difference
   between a CBoM and CAI is that the former is an extension of SBoM
   while the latter is centered around cryptographic assets that goes
   beyond software components.  The purpose of a CAI is to provide a
   comprehensive view of the cryptographic assets in use, their
   configurations, and their compliance with organizational policies and
   industry standards.  A CAI helps organizations manage their
   cryptographic assets effectively, ensuring that they are up-to-date,
   secure, and compliant with relevant regulations.  Think of it this
   way - CBoMs are part of SBoMs, HBoMs, and other BoMs.  CAI would be
   one schema that encompasses all instances of CBoMs in other BoMs.











Dev                      Expires 22 October 2026                [Page 3]

Internet-Draft             PQC CBoM Extension                 April 2026


3.  Components of a CAI

   An important feature of CBoM is its ability to provide detailed
   cryptographic properties at the component level. this essentially
   makes it use case independent.  By capturing the maximum information
   available, it can be used for a variety of use cases.  For CAI,
   however, we typically scope information that is relevant to
   cryptographic compliance.  For this document, the use case we focus
   on is the ability to provide enough information that would help an
   organization be compliant with existing cryptographic standards and
   future PQC standards.  Hence, a CAI should fulfil the following
   functions:

   1.  Criteria 1: At some level of grouping, provide a list of
       cryptographic assets that are present in the overall system.
       This system should encompass all assets, including software,
       hardware, and underlying infrastructure.  The grouping can be
       done at any feasible level, i.e., application, ownership,
       remediation team, etc.

   2.  Criteria 2: The inventory should provide compliance information
       according to current cryptographic standards.  These standards
       can be a combination of organizational encryption policy,
       industry standards for secure encryption, and regulatory
       requirements.

   3.  Criteria 3: The inventory should provide indicators of future
       quantum-resistant compliance.  This should include any newly
       standardized algorithms that are present in code, network, or
       infrastructure.

   4.  Criteria 4: The inventory should contain minimum information that
       would enable required parties to assess and manage cryptographic
       risks effectively.  It should not contain fields unnecessary for
       the purpose of inventorying.

   5.  Criteria 5: The inventory should to the extent possible, be
       automated for accurate updates to cryptographic information.

4.  Differences between CBoM and a Cryptographic Asset Inventory (CAI)

   We looked at the CryptoProperties schema in CycloneDX which is a
   representation of the original CBoM format [cyclone-cbom].  Based on
   the necessary properties of an organization level CAI, we identified
   the following areas in existing CBoM standards which can be augmented
   with additional information for a PQC inventory:

   1.  CBoM has a larger set of infomation that is use case independent



Dev                      Expires 22 October 2026                [Page 4]

Internet-Draft             PQC CBoM Extension                 April 2026


   2.  Complex inventories to inform PQC are hard to capture in the
       current structure

   3.  Clarity on mandatory versus optional fields needed

   4.  Hierarchy and relationships between cryptographic components are
       needed for understanding downstream effect

   5.  Additional information on criticality scoring would be helpful
       for asset prioritization

   6.  Chance of asset duplication

   7.  Need PQC-ready-compliance information in addition to CBoM
       information

   +=================+=============================+===================+
   |Enhancements     | Orignal CBoM Schema         |CBoM Extension     |
   +=================+=============================+===================+
   |Huge amount of   | CBoMs capture the maximum   |The extended       |
   |information      | set of information that can |format scopes down |
   |present.         | be collected about          |the fields         |
   |                 | cryptographic operations.   |required to make a |
   |                 | This approach makes         |migration decision |
   |                 | automation difficult and    |to quantum-        |
   |                 | leaves a lot of blank       |resistant          |
   |                 | values in the resulting     |cryptography.      |
   |                 | JSON schema.                |                   |
   +-----------------+-----------------------------+-------------------+
   |Fundamental      | Traditional BoMs designed   |The extended       |
   |structural issues| at an organizational level  |format maps assets |
   |when             | is a list of information    |at both            |
   |cryptographic    | that is hard to action      |organization,      |
   |assets           | unless mapped to specific   |application, and   |
   |(application,    | entities.  This approach    |owner level.  This |
   |framework,       | works well for single       |helps in mapping   |
   |library,         | products, but is hard to    |assets to teams    |
   |container,       | scale.  It also only works  |which have         |
   |operating-system,| for code-based inventory    |responsibilities   |
   |device, firmware,| where some contributor      |to make changes    |
   |or a file) are   | information might be        |and works for both |
   |mapped at        | available.                  |code-based and     |
   |“organization”   |                             |non-code-based     |
   |level.           |                             |cryptographic      |
   |                 |                             |assets.            |
   +-----------------+-----------------------------+-------------------+
   |No hierarchical  | The CycloneDX schema can    |Hierarchical       |
   |nature of crypto-| accept both related and     |system for assets  |



Dev                      Expires 22 October 2026                [Page 5]

Internet-Draft             PQC CBoM Extension                 April 2026


   |elements is      | unrelated asset type.  For  |and supporting     |
   |enforced, so     | example,                    |metadata added.    |
   |algorithms can   | cryptoProperties.assetTypes |                   |
   |exist in a CBoM  | can be an algorithm,        |                   |
   |without any      | certificate, protocol, or   |                   |
   |source           | relatedCryptoMaterial.      |                   |
   |attribution or   | However, a certificate can  |                   |
   |supporting       | be part of a protocol, an   |                   |
   |metadata.        | algorithm can be part of a  |                   |
   |                 | certificate, and the        |                   |
   |                 | relatedCryptoMaterial will  |                   |
   |                 | not work when assetType is  |                   |
   |                 | an algorithm.               |                   |
   +-----------------+-----------------------------+-------------------+
   |There is a chance| If asset types for both     |When assets are    |
   |of asset         | protocol and algorithm are  |mapped at          |
   |information      | recorded, their information |application level, |
   |duplication.     | can duplicate.  For e.g.,   |the extended       |
   |                 | ikev2TransformTypes and     |format ensures     |
   |                 | tlsCipherSuites can be      |unique             |
   |                 | captured under both         |identification and |
   |                 | protocol and algorithm      |tracking of each   |
   |                 | schema.                     |asset, reducing    |
   |                 |                             |the chance of      |
   |                 |                             |information        |
   |                 |                             |duplication,       |
   |                 |                             |especially because |
   |                 |                             |the algorithm      |
   |                 |                             |information itself |
   |                 |                             |is not the main    |
   |                 |                             |asset but a part   |
   |                 |                             |of it.             |
   +-----------------+-----------------------------+-------------------+
   |The utility of   | Without connection with     |Introduce fields   |
   |the produced     | internal policies, it will  |that can track     |
   |information in a | be hard to determine the    |compliance with    |
   |CBoM is quite    | relevance of the            |current standards  |
   |broad.           | information and make it     |and new quantum-   |
   |                 | actionable.  For e.g.,      |resistant          |
   |                 | algorithm information       |standards.         |
   |                 | without highlight if they   |                   |
   |                 | are deprecated or not is    |                   |
   |                 | hard to action.             |                   |
   +-----------------+-----------------------------+-------------------+
   |Missing          | Criticality scoring is      |Criticality        |
   |criticality score| missing.                    |scoring is         |
   |prevents         |                             |integrated into    |
   |determination of |                             |the schema, which  |



Dev                      Expires 22 October 2026                [Page 6]

Internet-Draft             PQC CBoM Extension                 April 2026


   |migration        |                             |can be updated     |
   |priority for     |                             |based on risk      |
   |high-risk        |                             |assessment         |
   |applications.    |                             |frameworks like    |
   |                 |                             |CARAF [caraf].     |
   +-----------------+-----------------------------+-------------------+

      Table 1: Comparison of Existing CBoM and CBoM Extension Against
                               CAI Criteria.

5.  Data Structure for CAI

   The standard CBoM structure as shown in Figure 1 (Section 5) has a
   total of 55 fields grouped by component type.  Each algorithm is a
   separate component "linked" by dependency.  The new structure for CAI
   as shown in Figure 2 (Section 5) has a total of 28 fields grouped by
   application.  Each application contains multiple crypto-elements with
   their respective properties.  The new structure is more compact and
   hierarchical, making it easier to understand and manage cryptographic
   assets at an application level for PQC needs.

   <CODE BEGINS> file "og-str"
                 Component (app/file/library/etc) {
                   Algo properties
                   Cert properties
                   Proto properties
                   Related cryptomaterial properties
                 }
   <CODE ENDS>

                        Figure 2: Original Structure

   The new structure Figure 2 (Section 5) also makes it easier for
   cryptographic assets to inherit the risk properties of its parent
   application.  The algorithm field is a sub-component wrapped inside a
   crypto-element, which in turn is wrapped in an application element.
   A noticeable change between the two is the inclusion of
   "Compliance_info", which specifies if certain algorithms are
   compliant or not.

   <CODE BEGINS> file "new-str"
               Application {
                 Application metadata {
                       Owner
                       Criticality
                       Other metadata
                   }
                 Crypto-elements {



Dev                      Expires 22 October 2026                [Page 7]

Internet-Draft             PQC CBoM Extension                 April 2026


                   Source: code {
                         Certificates {
                           Algorithm and compliance info
                           Crypto-element metadata
                         }
                         Crypto Libraries {
                           Algorithm and compliance info
                           Related Crypto Materials (keys, IVs, nonces)
                         }
                         Cert/library/proto {
                           Algorithm and compliance info
                           Crypto-element metadata
                         }
                     }
                   Source: network {
                         Protocols {
                           Algorithm and compliance info
                           Crypto-element metadata
                         }
                         Certificates {
                           Algorithm and compliance info
                           Crypto-element metadata
                         }
                       }
                     Source: infrastructure {
                           Internal {
                             Infra Type
                             (Container, OS, Hardware, Cloud services, Devices, Files)
                             {
                               Algorithm and compliance info
                               Crypto-element metadata
                             }
                           }
                           External {
                             Infra Type
                             (Container, Hardware, Cloud services, Files)
                             {
                               Algorithm and compliance info
                               Crypto-element metadata
                             }
                           }
                       }
                   }
               }
   <CODE ENDS>

                          Figure 3: New Structure




Dev                      Expires 22 October 2026                [Page 8]

Internet-Draft             PQC CBoM Extension                 April 2026


   Using the CBoM schema as the standard template and adding the
   additional elements, we observe the following overall structure.

   +=================================+===================================================+
   |PQC Use Case Schema              |Existing CBoM Schema Equivalent                    |
   +=================================+===================================================+
   |application_ID                   |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.owner             |component.authors                                  |
   +---------------------------------+---------------------------------------------------+
   |application_ID.criticality       |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |component.name                                     |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |                                                   |
   |.responsible_entity              |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |                                                   |
   |.purpose                         |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |                                                   |
   |.compliance.is_compliant         |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |                                                   |
   |.compliance.is_PQC_vulnerable    |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |                                                   |
   |.compliance.upgradeable          |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |                                                   |
   |.compliance.compliance_message   |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |cryptoProperties.scanner                           |
   |.source[y]                       |                                                   |
   |(0=code.source_name,             |                                                   |
   |1=network.source_name,           |                                                   |
   |2=infra.source_name)             |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |                                                   |
   |.source[0].repo_name             |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |                                                   |
   |.source[x].discovery_date        |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |cryptoProperties.assetTypes                        |
   |.type[x]                         |                                                   |
   |(0=library, 1=protocol,          |                                                   |
   |2=certificate)                   |                                                   |



Dev                      Expires 22 October 2026                [Page 9]

Internet-Draft             PQC CBoM Extension                 April 2026


   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |cryptoProperties.algorithm.variant                 |
   |.type[x].algorithm_in_use        |                                                   |
   |                                 +---------------------------------------------------+
   |                                 |cryptoProperties.protocol.tlsCipherSuites          |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |cryptoProperties.algorithm.implementationPlatform  |
   |.type[x].device_info             |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |cryptoProperties.certificate.certificateAlgorithm  |
   |.type[x].signature_algorithm_name|                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |cryptoProperties.relatedCryptoMaterial.size        |
   |.type[x].key_size                |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |cryptoProperties.oid                               |
   |.type[x].signature_algorithm_oid |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |cryptoProperties.detectionContext.filepath         |
   |.type[x].asset_path              |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |                                                   |
   |.type[x].curve_name              |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |cryptoProperties.detectionContext.lineNumbers      |
   |.type[0].line                    |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |cryptoProperties.detectionContext.additionalContext|
   |.type[0].code_block              |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |cryptoProperties.confidenceLevels.variant          |
   |.type[0].confidence_level        |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |                                                   |
   |.type[1].protocol_name           |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |cryptoProperties.certificate.notValidAfter         |
   |.type[2].expiry_date             |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |                                                   |
   |.type[2].parent_cert_references  |                                                   |
   +---------------------------------+---------------------------------------------------+
   |application_ID.asset_ID          |cryptoProperties.certificate.issuerName            |
   |.type[2].issuer                  |                                                   |
   +---------------------------------+---------------------------------------------------+
   |                                 |+39 rows not added                                 |
   +---------------------------------+---------------------------------------------------+




Dev                      Expires 22 October 2026               [Page 10]

Internet-Draft             PQC CBoM Extension                 April 2026


      Table 2: Overall Mapping of Proposed Extended CBoM based on CAI
       Schema to CBoM Schema.  The fields on the left is the extended
                          schema for PQC use case.

   The above table maps the proposed CAI schema fields to their
   equivalent CBoM schema fields.  Not all fields have a direct
   equivalent, indicating areas where the CAI schema introduces new
   concepts or structures not present in the original CBoM schema.

6.  Conclusion

   In this document, we proposed an extension to the existing CBoM
   schema to better suit the needs of an organizational level
   Cryptographic Asset Inventory (CAI).  By identifying gaps in the
   current CBoM standards and introducing a more hierarchical and use-
   case focused structure, we aim to provide a more effective schema for
   organizations to manage their cryptographic assets, ensuring
   compliance with current and future standards, including post-quantum
   cryptography requirements.  Future work includes developing tools for
   automated generation and maintenance of CAI based on this proposed
   schema.

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Security Considerations

   This document should not affect the security of the Internet.

9.  References

9.1.  Normative References

   [cbom]     IBM, "IBM is donating its CBOM toolset to the Linux
              Foundation", 2025, <https://research.ibm.com/blog/
              cryptographic-cbom-linux-foundation>.

   [cyclone-cbom]
              OWASP, "CycloneDX: An Authoritative Guide to CBOM", 2025,
              <https://cyclonedx.org/guides/OWASP_CycloneDX-
              Authoritative-Guide-to-CBOM-en.pdf>.

   [caraf]    Ma, CM., "CARAF: Crypto Agility Risk Assessment
              Framework", 2021,
              <https://academic.oup.com/cybersecurity/article/7/1/
              tyab013/6289827>.




Dev                      Expires 22 October 2026               [Page 11]

Internet-Draft             PQC CBoM Extension                 April 2026


Acknowledgements

   This template uses extracts from templates written by Pekka Savola,
   Elwyn Davies and Henrik Levkowetz.

Contributors

   Thanks to all of the reviewers of this initial draft.

Author's Address

   Jayati Dev (editor)
   Comcast
   1800 Arch St
   Philadelphia, Pennsylvania 19130
   United States of America
   Email: Jayati_Dev@comcast.com


































Dev                      Expires 22 October 2026               [Page 12]
