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 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... 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. file "og-str" Component (app/file/library/etc) { Algo properties Cert properties Proto properties Related cryptomaterial properties } 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. 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 } } } } } 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, . [cyclone-cbom] OWASP, "CycloneDX: An Authoritative Guide to CBOM", 2025, . [caraf] Ma, CM., "CARAF: Crypto Agility Risk Assessment Framework", 2021, . 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]