CBOM: add protocol registry schema - #1010
Conversation
Defines protocols by family and version, alongside the existing algorithm families and elliptic curves. Each version carries a composition: a list of functional slots that all apply. A slot holds an algorithm set; "selection" states whether all, one or more, or exactly one of the set are used at runtime, and "selectedBy" how that choice is made (negotiation, configuration, ...). Set members are algorithm names that resolve against the variant patterns of the algorithm registry, or named bundles of such names (cipher suites, hybrid key exchange groups). The TLS 1.3 entry is illustrative for now; the list will be populated further. Signed-off-by: Basil Hess <bhe@zurich.ibm.com>
Mehrn0ush
left a comment
Mehrn0ush
left a comment
There was a problem hiding this comment.
Hi,
The composition model and TLS 1.3 example make sense to me. I left a few inline questions on join semantics, pattern resolution, and selectedBy; all minor while this is draft.
One more thing I didn’t inline is: the registry looks like “what a protocol version can negotiate,” while existing protocolProperties.cipherSuites / IKEv2 fields describe this instance. A short note on that layering (and how registry names relate to IANA-style identifiers in CBOMs) would make the split clearer for implementers.
| "description": "Defines a specific protocol version and its algorithm composition.", | ||
| "additionalProperties": false, | ||
| "properties": { | ||
| "version": { |
There was a problem hiding this comment.
How should tools join this to a BOM? Is the lookup an exact match on protocolProperties.type + protocolProperties.version → family + this version string (e.g. "1.3" only)? Worth documenting, since there’s no schema $ref or uniqueness constraint on the pair.
| "algorithmSet" | ||
| ] | ||
| }, | ||
| "algorithmSet": { |
There was a problem hiding this comment.
Pattern matching isn’t enforced by JSON Schema here — only plain strings. right? For PQ-readiness queries, should there be a short resolution rule (or CI check) so bad names don’t silently fail lookup?
| "description": "The set of algorithms that can fill this slot." | ||
| } | ||
| }, | ||
| "required": [ |
There was a problem hiding this comment.
selectedBy is in the PR description and all TLS examples, but it’s not required here. Intentional, or should it be required when selection is one-of / any-of?
2 participants
Summary
This adds a protocol registry to
cryptography-defs, alongside the existing algorithm families and elliptic curves. Protocols are defined per family and version, each with its algorithm composition, so tools can answer questions like "can this protocol version negotiate a post-quantum key exchange?" without every CBOM re-describing the protocol.The TLS 1.3 entry is illustrative for now; the list will be populated further (TLS 1.2, SSH, IKEv2, ...).
What's added
A new top-level
protocolsarray. Each protocol version carries acomposition: a list of functional slots that all apply together.role: what the slot does (key-exchange,signature, ...); open string with examples, likevariant.primitive.selection: how many algorithms of the set are used at runtime:all-of,any-of, orone-of.selectedBy: how that choice is made:negotiation,configuration,server-selected, ...algorithmSet: algorithm names matching the variant patterns of the algorithm registry, or named bundles{name, algorithms[]}for cipher suites and hybrid key exchange groups.Example, TLS 1.3 key exchange:
{ "role": "key-exchange", "selection": "one-of", "selectedBy": "negotiation", "algorithmSet": [ "x25519", { "name": "X25519MLKEM768", "algorithms": ["x25519", "ML-KEM-768"] } ] }Backwards compatibility
No breaking changes,
protocolsis optional.protocolFamiliesEnumuses the same tokens asprotocolProperties.type, so a BOM references a registry entry viaprotocolProperties.typeplusversion.. no new field in the core schema needed.