Cryptographic Asset Discovery and Inventory
draft-liu-cadi-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Peter Chunchi Liu | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liu-cadi-01
Network Working Group C. P. Liu
Internet-Draft Huawei
Intended status: Standards Track 6 July 2026
Expires: 7 January 2027
Cryptographic Asset Discovery and Inventory
draft-liu-cadi-01
Abstract
This document compiles existing Cryptographic Asset Discovery and
Inventory (CADI) methods and analyze potential gaps.
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 7 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Liu Expires 7 January 2027 [Page 1]
Internet-Draft CADI July 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement and Challenges . . . . . . . . . . . . . . 3
4. Discovery and Identification . . . . . . . . . . . . . . . . 4
4.1. Active Identification . . . . . . . . . . . . . . . . . . 5
4.1.1. Cryptographic Bill of Materials (CBOM) and Auxiliary
Methods . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Passive Identification . . . . . . . . . . . . . . . . . 7
4.2.1. Simulated Handshakes . . . . . . . . . . . . . . . . 7
4.2.2. Traffic Pattern Analysis . . . . . . . . . . . . . . 9
4.2.3. Process Identification . . . . . . . . . . . . . . . 9
4.2.4. Configuration Extraction . . . . . . . . . . . . . . 10
5. Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Potentially Related Working Groups . . . . . . . . . . . . . 11
7. Tools Compilation . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Cryptographic Asset Discovery and Inventory (CADI) refers to a set of
tools and guidelines that assist in identifying, collecting,
normalizing, correlating, and continuously maintaining all
cryptography-related assets, including configurations, dependencies,
and usage contexts within a given organization, system, or product
scope. It requires both technical tools and management approaches.
Many Post-Quantum transition roadmaps have highlighted the importance
of identifying legacy cryptographic assets inside of an organization
as a crucial preparatory part. For example:
* The G7 statement on "Advancing a Coordinated Roadmap for the
Transition to Post-Quantum Cryptography in the Financial Sector"
[G7] mentions there should exist six key PQ-migration activities:
- Awareness and Preparation, *Discovery and Inventory*, Risk
Assessment and Planning, Migration Execution, Migration
Testing, Validation and Monitoring. The exact six stages are
also published in NCCoE analysis on "Six Key Phases of the PQC
Migration Journey" [NCCOEFAQ].
Liu Expires 7 January 2027 [Page 2]
Internet-Draft CADI July 2026
* The United States Memorandum for the Heads of Executive
Departments and Agencies on "Migrating to Post-Quantum
Cryptography" [OMBM2302] requires:
- All federal agencies to "*Submit cryptographic system inventory
By May 4, 2023 and annually thereafter*". This important date
is also mentioned in CISA directive "Strategy for Migrating to
Automated Post-Quantum Cryptography Discovery and Inventory
Tools"[CISAACDI].
Although the exact PQ-migration roadmap in each different nations
varies, the fact that cryptographic asset discovery and inventory is
a key prerequisite for Chief Information Security Officers to asses a
migration budget and draft a migration plan does not change. In this
draft, we analyze existing CADI methods and potential gaps.
2. Terminology
* CADI (Cryptographic Asset Discovery and Inventory) -- A set of
tools and guidelines designed to automate the identification,
collection, normalization, correlation, and lifecycle management
of an organization's cryptographic assets.
* Cryptographic Asset -- A digital or physical element within a
device or service-such as an algorithm, module, configuration,
credential, secret, or communication protocol-that protects the
confidentiality and integrity of secure data transmission or
storage.
* Cryptographic System -- An active software or hardware
implementation of one or more cryptographic algorithms that
provide one or more of the following services: (1) creation and
exchange of encryption keys; (2) encrypted connections; or (3)
creation and validation of digital signatures. (according to
[OMBM2302])
* Cryptographically Relevant Quantum Computers (CRQC) -- A fault-
tolerant quantum system capable of solving the underlying hardness
assumption problems of widely used public-key cryptography in
polynomial time, such as RSA and ECC.
3. Problem Statement and Challenges
Apart from the milestones and requirements discussed above, there are
also a few challenges to identify cryptographic assets:
Liu Expires 7 January 2027 [Page 3]
Internet-Draft CADI July 2026
* Legacy ICT systems were not engineered to treat cryptographic
primitives as distinct, trackable assets. Instead, cryptographic
implementations are deeply integrated, highly distributed, and
hidden across heterogeneous layers of the technology stack.
* Taking inventory manually would take enormous amount of effort,
yet there may still be statistical omissions that leave security
exposures.
* Methods like Cryptographic Bill of Materials (CBOM) only take
effect on new devices to self-announce its cryprographic assets,
but it cannot help identify legacy devices and systems.
* Legacy devices and systems often behave like blackboxes, many does
not allow installing additional programs or tools on them.
As a result, the ideal CADI tool should meet the following
requirements:
* *Automated* scanning and inventory taking
* *Agnostic* to target object's system designs and architectures
* *Integrate* the result to existing network management and
operations systems for unified presentation
The requirements for automation, architectural agnosticism, and
network management integration suggest a protocol-driven approach,
potentially placing this within the scope of the IETF. However, this
remains open for discussion.
4. Discovery and Identification
There are many ways of doing discovering and identification. We
catagorize them into two: active identification and passive
identification.
* *Active Identification*: The case where devices and services
modifies its development and/or management process, actively self-
announcing their cryptographic assets. Methods falls into this
category includes:
- CBOM Declaration
- Static Code Scanning
- Binary / Image Scanning
Liu Expires 7 January 2027 [Page 4]
Internet-Draft CADI July 2026
- CI/CD Integration
* *Passive Identification*: The case where devices and services will
stay as-is and cannot self-announce their cryptographic assets.
These devices will require additional external tools to assist the
identification. Methods falls into this category includes:
- Simulated Handshakes
- Configuration Extraction
- Traffic Pattern Analysis
- Process Identification
4.1. Active Identification
4.1.1. Cryptographic Bill of Materials (CBOM) and Auxiliary Methods
CBOM-based identification is to empower cryptographic asset owners or
vendors to explicitly declare cryptographic usage within their
products, components, or services. Usually CBOM declaration is
achieved through static code scanning and/or CI/CD integration, so we
keep them in the same section.
*Scanning Methods:*
* *Static Code Scanning*:
- SCA (Software Composition Analysis): Scan manifest files (like
package.json, requirements.txt, or pom.xml) from the codebase
to create CBOMS, usually for analyzing third-party libraries
dependency.
- SAST (Static Application Security Testing): Builds a Abstract
Syntax Tree (AST) with parsed syntax and data flow of the
target source code. It then uses AST to track call chain to
end crypto library, track variables (data flow) from source to
destination, do reference matching, etc.
o SCA and SAST is used by IBM CBOMKit-Hyperion.
* *Binary / Image Scanning*:
- Scan for algorithmic constants, signatures; Extract from OS
trust stores and runtime configurations... The process details
are omitted in this document due to complexity.
Liu Expires 7 January 2027 [Page 5]
Internet-Draft CADI July 2026
o Binary / Image Scanning is used by IBM CBOMKit-Theia and
CycloneDX Cdxgen.
*Tools and Modelling:*
* *IBM CBOMkit*, Static code level scanning (Hyperion) and Artifact
level scanning (Theia) [IBMCBOM]: uses implements and uses
relationship to create dependency diagram.
- implements: Describes the list of protocols or algorithms this
module implements.
- uses: Describes what modules are used by this service.
- For example, Application Nginx uses Library libssl.so that uses
Protocol TLS v1.3/v1.2 that uses libcrypto.so that implements
Algorithm MD5, SHA256, AES-128-GCM.
* *CycloneDX Cdxgen*, Artifact level scanning [CDXGEN]: uses
dependsOn and provides relationship to create dependency diagram.
- dependsOn: Describes other modules or services this module
depends on.
- provides: Describes all capabilities this module provides.
- For example, Application Nginx dependsOn Library libssl.so ,
which provides TLS 1.2.
After scanning, the result will be recorded as a CBOM object.
*CBOM data specification:* A standardized cryptographic asset object
includes cryptographic algorithms, digital certificates, protocols,
private keys, public keys, cryptographic keys, ciphertext
information, digital signatures, digests (the output values of hash
functions), initialization vectors (input parameters for encryption
algorithms), seeds, salts, shared secrets, authentication tags,
passwords, credentials, and tokens. For a detailed specification,
see CycloneDX SBOM v1.6 https://cyclonedx.org/news/cyclonedx-
v1.6-released/
Liu Expires 7 January 2027 [Page 6]
Internet-Draft CADI July 2026
"components": [
{
"name": "google.com",
"type": "cryptographic-asset",
"bom-ref": "crypto/certificate/google.com@sha256:1e15e0fbd3ce9...",
"cryptoProperties": {
"assetType": "certificate",
"certificateProperties": {
"subjectName": "CN = www.google.com",
"issuerName": "C = US, O = Google Trust ... LLC, CN = GTS CA 1C3",
"notValidBefore": "2016-11-21T08:00:00Z",
"notValidAfter": "2017-11-22T07:59:59Z",
"signatureAlgorithmRef": "crypto/algorithm/sha-512-rsa@1.2.840..",
"subjectPublicKeyRef": "crypto/key/rsa-2048@1.2.840.113549.1.1.1",
"certificateFormat": "X.509",
"certificateExtension": "crt"
}
}
_Figure 1: Example CBOM_
*Gaps:* Obviously, this does not help with identifying the mass
legacy devices, components or services.
4.2. Passive Identification
4.2.1. Simulated Handshakes
Simulated handshake is a network-probing technique where a discovery
tool acts as a client and intentionally initiates cryptographic
protocol negotiations (e.g., TLS, SSH, IPsec) with enterprise network
endpoints without completing the full data session. During the
negotiation process, the discovery tool determines the specific
cryptographic protocol versions, negotiation mechanisms, and
ciphersuites supported by the endpoint. This is also known as
_Active Probing_.
*Steps of simulated handshake include:*
1. *Port Scan:* The tool scans for typical ports for specific secure
communication protocols (443 for HTTPS, 22 for SSH, etc)
2. *Probing:* The tool generates a RFC-compliant connection
initialization packet, including all currently standardized
ciphersuites, and examine the response.
3. *Response Extraction:* The target object respond with supported
ciphersuites, following its own internal priority rules.
Liu Expires 7 January 2027 [Page 7]
Internet-Draft CADI July 2026
4. *Parsing:* The tool intercepts this raw response and decodes it
as cryptographic assets.
This works for most secure protocols that includes negotiation:
* IPSEC
* TLS
* SSH
*Pros and Cons/Gaps:*
* Strengths:
- This kind of method does not require complex engineering
refactoring. Since it is agnostic to the design of the target,
it works best for the case where the manager operates vast
heteogenous devices from different vendors, versions and
locations, hence telecommunications case.
- This probing is one-time, thus it will not create unhandleable
amount of probing packets.
* The limitation of this method is that
- Some masking mechanism will stop the probing (firewalls, load
balancers, port-concealing protocols like Single Packet
Authorization that enforce a default drop for unexpected
packets), leaving a hidden security posture inside of the
system.
- Network management cannot know local application components
that rests internally in the device and are not exposed over a
socket.
*Tools:*
* Cisco Mercury project [MERCURY] provides an open source packet
capture and analysis tool. It can read network packets, identify
metadata of interest, and write out the metadata (including
cryptographic-related) in JSON format.
Liu Expires 7 January 2027 [Page 8]
Internet-Draft CADI July 2026
4.2.2. Traffic Pattern Analysis
Unlike simulated handshakes that actively query an endpoint, Traffic
Pattern Analysis listens passively to live network traffic at
strategic aggregation points. It infers cryptographic asset usage
from protocol metadata, statistical characteristics, and behaviors
without decrypting the underlying data payload.
*Methods of Traffic Pattern Analysis includes:*
* Listen to unencrypted negotiations like clientHello/serverHello,
Server Name Indication (SNI), response of an unencrypted server
digital certificate request, etc.
* Listen to handshake fingerprints and compare them to existing
patterns, as protocol implementations and behaviors are often
rigid.
* Listen to packet length and arrival time, do statistical pattern
recognition.
*Pros and Cons/Gaps:*
* Strengths:
- Similar to Simulated Handshakes, this kind of method is not
intrusive and is agnostic to the design of the target.
* The limitation of this method is that
- Negotiation information like clientHello [RFC9849] and SNI are
tending to be encrypted.
- Protocols tend to have constant size packets [RFC9347].
- Alternative routing: network requests/responses could exit
through a different routing path.
4.2.3. Process Identification
Process Identification requires Endpoint Detection and Response (EDR)
installed to have cryptographic visibility inside of a system.
*Methods of Process Identification includes:*
Liu Expires 7 January 2027 [Page 9]
Internet-Draft CADI July 2026
* Kernel-Level System Call Auditing by deploying eBPF programs into
the kernal space. These filters can capture kernel events to
determine exactly which process (down to PID) have initiated an
encrypted network communication.
* Shared Library and Binary Hooking, by monitoring process load
table to see if cryptographic dynamic libraries are loaded into
the memory space.
* Live Memory Scanning, by periodically scanning volatile memory for
indication of creation of keys or signatures (as high-entropy
memory segments), and then compare them with known patterns.
*Pros and Cons/Gaps:*
* Strengths:
- Have deeper visibility for cryptographic assets within devices.
* The limitation of this method is that
- Requires loading new software (at least EDR/RDR) to legacy
devices.
- Potential blind spots due to lower pattern coverage.
4.2.4. Configuration Extraction
The Configuration Extraction is a bit similar to the source code
scanning. This section focuses more on the runtime configurations.
In different use cases, the configuration extraction methods differs
significantly. This section is to be extended.
*Methods of Configuration Extraction includes:*
* In network device management, NETCONF and YANG provide a
standardized, model-driven management interface that enables
programmable configuration and state validation. The network
managing platform can define a YANG model and extract
configurations from a device.
* In cloud-native development, general .yaml configuration files,
.env environment variables files, Kubernetes secret manifest, etc,
can be extracted by administrative scripts or through management
interfaces (e.g., AWS CloudControl, Kubernetes API).
Liu Expires 7 January 2027 [Page 10]
Internet-Draft CADI July 2026
5. Inventory
TBD: After discovery, the result should best be presented in a
unified network management platform for a comprehensive view. The
Network Inventory (IVY) working group is working on this topic and
cryptographic properties could become extensions to IVY records. The
details of this section could invite more network management experts
for input.
6. Potentially Related Working Groups
* IVY -- extend network management views with cryptographic
attributes.
* SCITT -- extend SBOMs to adapt CBOMs.
* PQUIP -- as a migration guideline.
7. Tools Compilation
Due to limited time, compiling existing CADI tools remain open and
will be done in next version.
8. Security Considerations
This document has no further security considerations.
9. IANA Considerations
This document has no IANA actions.
10. References
10.1. Normative References
[RFC9849] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849,
March 2026, <https://www.rfc-editor.org/rfc/rfc9849>.
[RFC9347] Hopps, C., "Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for IP
Traffic Flow Security (IP-TFS)", RFC 9347,
DOI 10.17487/RFC9347, January 2023,
<https://www.rfc-editor.org/rfc/rfc9347>.
10.2. Informative References
Liu Expires 7 January 2027 [Page 11]
Internet-Draft CADI July 2026
[G7] "Advancing a Coordinated Roadmap for the Transition to
Post-Quantum Cryptography in the Financial Sector",
January 2026, <https://home.treasury.gov/system/files/136/
G7-CEG-Quantum-Roadmap.pdf>.
[CISAACDI] "Strategy for Migrating to Automated Post-Quantum
Cryptography Discovery and Inventory Tools", August 2024,
<https://www.cisa.gov/sites/default/files/2024-09/
Strategy-for-Migrating-to-Automated-PQC-Discovery-and-
Inventory-Tools.pdf>.
[NCCOEFAQ] "Frequently Asked Questions about Post-Quantum
Cryptography", June 2026, <https://pages.nist.gov/nccoe-
migration-post-quantum-cryptography/FAQ/index.html>.
[OMBM2302] "MEMORANDUM FOR THE HEADS OF EXECUTIVE DEPARTMENTS AND
AGENCIES, Migrating to Post-Quantum Cryptography",
November 2022, <https://www.whitehouse.gov/wp-
content/uploads/2022/11/M-23-02-M-Memo-on-Migrating-to-
Post-Quantum-Cryptography.pdf>.
[NIST-SP-1800-38B]
"Migration to Post-Quantum Cryptography Quantum Readiness-
Cryptographic Discovery", December 2023,
<https://www.nccoe.nist.gov/sites/default/files/2023-12/
pqc-migration-nist-sp-1800-38b-preliminary-draft.pdf>.
[MERCURY] "Mercury - network metadata capture and analysis.", n.d.,
<https://github.com/cisco/mercury/>.
[IBMCBOM] "CBOM", n.d., <https://github.com/IBM/CBOM>.
[CDXGEN] "CycloneDX Generator", n.d.,
<https://github.com/cdxgen/cdxgen>.
Author's Address
Chunchi Peter Liu
Huawei
China
Email: liuchunchi@huawei.com
Liu Expires 7 January 2027 [Page 12]