The cryptographic relationship model

This section fixes the vocabulary the rest of the methodology is written in. A profile states which facts a CBOM must disclose, and those statements are only as precise as the terms they use. Settling the terms is therefore a prerequisite for writing a profile.

Why this section exists

The questions that CBOMs are asked to answer are mostly questions about use, not about inventory. "Which algorithms does this product implement?" is an inventory question, and it is the easier one. "Which of our connections would still be readable if an adversary recorded them today?" is a question about where cryptography is applied, between whom, and under what negotiated terms. Migration planning, procurement conformance, and incident response all sit closer to the second question than the first.

Current CBOM standards answer the first question well. They provide objects for algorithms, keys, certificates, and protocols, with fields for their parameters. They provide no object for the use of those assets between two parties. The consequence is that facts belonging to a connection have to be attached to whichever asset is nearest, which works while there is one obvious connection per product and becomes unreliable as soon as there is not.

This has a direct effect on profiles. The example profile requires a product to declare its cryptographic interfaces and to include a management interface among them. That requirement means nothing unless "interface" has an agreed definition, unless it is clear that an interface is not the same thing as an algorithm, and unless a producer and a consumer will count the same set of interfaces when they read the same document. Product rule P2 is a statement about relationships, and it is checkable only because the terms below are fixed.

This section therefore does four things: it defines the three terms, draws the boundary between them by showing what is not a relationship, works through examples chosen to break the assumptions that a simple TLS session quietly supports, and records one case the current model does not cover.

The three terms

Why the term is "relationship"

Two other terms were considered and set aside. Interface reads naturally for a network connection between two systems, and it over-fits: it suggests two parties communicating at the same moment over a link, which excludes several of the cases below. It is retained in the profile as interfaceType and interfaceId for the subset of relationships that are interfaces, but not as the general term. Cryptographic context collides with established usage, where a context is the runtime state held by a cipher implementation. Cryptographic relationship carries no prior technical meaning in this space and describes what the thing is, so it is the settled term.

A fourth thing: what the cryptography is for

A relationship says where cryptography is applied and an asset says what is applied. Neither says what job it is doing, and the job is what determines when it can change. A cryptographic purpose is that job: establishing a key, encrypting, proving identity, protecting a message from modification, signing something that must verify years later, protecting keys, deriving keys.

A purpose is not an operation, and the difference is easy to lose. CycloneDX records operations in cryptoFunctions: sign, verify, encrypt, keyagreement. A TLS certificate signature and a firmware signature are both sign and verify. One proves identity during a session and changes when the certificate hierarchy does; the other must still verify long after it was written, and changes only when the last verifier in the field has been upgraded. Same operation, different decade, different work to do. An operation describes the algorithm; a purpose describes the use, and only the use carries a timetable.

Two consequences follow for anyone writing rules.

A purpose does not partition assets. AES-GCM serves encryption and data integrity at the same time, and a certificate signature can serve entity authentication in one deployment and non-repudiation in another. A rule written as "each algorithm has a purpose" is therefore wrong; an asset may appear under several, and the count of purposes at an interface is not the count of its algorithms.

A purpose belongs to a relationship, not to a product. A product that terminates TLS and also signs firmware is doing different jobs at different boundaries, on different schedules. Purpose attaches where the cryptography is applied, which is the relationship, and the same product may hold one purpose in a settled state at one interface and an unsettled state at another.

The vocabulary, and the four-part test an entry has to pass to join it, are in Terms. The PQC Migration profile shows why the distinction is load-bearing: capability is stated once per purpose, because key agreement and identity proof migrate on different timetables and a single answer would have to report the worse of the two.

What is not a relationship

The distinction is easier to hold once the boundary is drawn from the other side. Each pair below states a node fact and the corresponding edge fact. The left column is what an asset inventory records. The right column is what a migration decision needs.

The most common modelling error is to record a left-column fact and treat it as though it answered a right-column question. Capability is not the same as use: that a product can perform an operation is not evidence that any particular connection performs it.

Worked examples

A single TLS session makes the terms easy to state and easy to underestimate, because the two parties are obvious and present at the same moment. The examples below are chosen because each one breaks a different assumption that the TLS case quietly supports.

1 · One apparent connection is several relationships

A browser connects to a service through a content delivery network or a load balancer. The user sees one padlock. There are at least two relationships, and the cryptography on each is chosen independently. It is common for the public leg to be modern while the leg behind it uses an older protocol version, or none at all, on the reasoning that the network is private.

2 · The parties are separated in time, not space

An encrypted backup or archive has two parties: the process that writes it and whatever reads it later. There is no session, and the second party may not exist yet. The relationship still has all the properties that matter, including a lifetime, which here is the retention period rather than the duration of a connection.

This case decides harvest-now-decrypt-later urgency. The bulk algorithm is usually adequate. The exposure sits in the key wrapping, and whether it matters depends on how long the data must stay confidential, which is a property of the relationship and not of any algorithm in it.

3 · The parties never interact

A publisher signs firmware or code. A relying party verifies the signature, possibly years afterwards, with no communication between them in either direction. The relationship is one of trust rather than exchange, and its failure has consequences.

For migration, the constraint in this case sits at the far end. A publisher can adopt a post-quantum signature algorithm whenever it wishes, and gains nothing if the deployed devices cannot verify it. The relationship's ceiling is set by the verifier, which may be a device with no update path.

4 · Relationships overlap on the same wire

Transport security and message-level security protect different spans. A signed token travels inside a TLS session, and the two do not share endpoints. Where a gateway terminates TLS, the transport relationships run from client to gateway and from gateway to service, while the signature relationship runs from the originator to the final recipient and passes through the gateway untouched.

This matters when a consumer asks what protects a given piece of data end to end. The answer differs by layer, and a model that records one relationship per connection cannot express it.

5 · One asset, many relationships

A gateway with a single IPsec implementation may hold tunnels to many peers. An operator's interconnect, a service mesh, and a partner VPN estate all have this shape. The implementation is one asset. The relationships are many, and their properties differ because each peer negotiates separately.

Post-quantum readiness is therefore not a property that a product can hold on its own. An organization may deploy a fully capable gateway and still have most of its tunnels running classical key exchange, because readiness on any given tunnel depends on the other side as well.

6 · Capability is not the negotiated outcome

Two systems both implement a post-quantum key exchange. The session between them uses a classical group, because of a configuration setting, an intermediary that rejects the larger handshake, or a policy on one side. Both node records are accurate. The connection is nevertheless not quantum-safe.

There is no node on which this fact can be stored. It belongs to the relationship, and it cannot be derived from either endpoint's inventory entry. This is the clearest case for treating the edge as a first-class object rather than an annotation on an asset.

7 · The weaker party sets the ceiling

A modern gateway communicates with a controller installed twenty years ago. The gateway supports current algorithms. The controller supports what it shipped with and cannot be changed. The relationship's posture is fixed by the less capable end, and no upgrade to the gateway alters it.

Planning that works from a product inventory will schedule an upgrade that cannot deliver the intended result. Planning that works from relationships identifies the controller as the item requiring replacement, which is a different and usually more expensive piece of work.

8 · Relationships that carry no data

An application uses a key held in a hardware security module or a trusted execution environment. The key never leaves the module. What passes between them are requests to use the key and the results of those operations. The relationship is one of custody and control, and it crosses a hardware boundary rather than a network.

The distinction has practical weight for migration. If the key material is confined to hardware, adopting a new algorithm may require the module to support it, which can mean replacement rather than reconfiguration.

A known limitation: one-to-many relationships

Every example above is pairwise. Some cryptography is not. A broadcast or multicast group, a mobile air interface serving many receivers, and a group messaging session all apply cryptography among more than two parties at once, and the natural representation is a relationship with n endpoints rather than two.

One-to-many is two cases, not one, and only the first is expensive. A shared key held by n parties at once is the case above: no pairwise description of it is true, so the model has to change to carry it. A signature verified by a population is different. One party signs, many verify, each holding its own keys, and every leg decomposes into a pairwise relationship without loss. What is missing there is not a relationship with n endpoints but a way to name the population that fixes the ceiling, which is a smaller change and is recorded separately as Q46. A closely related gap, naming the trust anchor and whether membership under it is administered, is recorded as Q47. Financial settlement and payment rails were raised as a case for the shared-key limitation and appear to be an instance of these two instead; the reasoning is in the multi-party trust design note.

Summary: a taxonomy of relationships

Taken together the examples vary along four dimensions: how many parties there are, whether those parties exist at the same time, what passes between them, and how far the protection extends. Setting them out in one place shows that the model is more general than the network connection it is usually explained with, and gives a way to test it against a case from a new sector.

The dimensions also indicate where a profile written for one sector will need rules that another does not. A profile concerned with data at rest has to address the retention period, which does not arise for a session. A profile concerned with signing has to address the population of verifiers, which has no counterpart in a transport profile. The same table appears in the profile specification at profile-interface-disclosure.md, where it defines the scope a profile applies to.