[Mehrn0ush]

The issue asked for a role on related assets. Basil pointed out that the asset already states its functions, and with the TLS and SSH properties the positions are covered too. So I've updated this PR to a small documentation fix: the type description there was a copy of the securedBy text. Nothing else is in it now.

Also updates four existing fixture entries from publicKey to public-key.

Thanks @bhess

• Related to Better support for the arrangement of cryptographic algorithms in various security protocols, such as SSH and TLS 1.3. #1162.

[bhess]

Thanks @Mehrn0ush for picking this up! I'm not convinced that a free-text role is the right solution, mainly because it's hard to define precisely what a role is.

• Most of the example roles (encryption, mac, signature, key-exchange) are cryptographic functions, which the referenced asset already states via keyUsage for keys or cryptoFunctions for algorithms. Both use the cryptographicFunction enum, which I think is better than an open string, since it keeps CBOMs comparable.
• I also see a role less as a property of the asset itself, and more as how another component uses it, e.g. an application that signs code with a key. For that, the 2.0 behaviors (e.g. security:cryptography:signsCode) seem a better fit. What might be missing today is a way to link a behavior to the key or algorithm used for it. Longer term, labelled dependencies could cover this, and the blueprint relationships already have typed edges we could build on.

Maybe blueprints already cover the last point, would be a good discussion point for this week's meeting.

[Mehrn0ush]

Thanks @bhess. You are right. free-text role, and the later functions rework, are both removed: the referenced asset already states its functions through cryptoFunctions and keyUsage, and protocol positions are better expressed by protocol-specific properties (#1184 for TLS, #1200 for SSH). How another component uses an asset is discussed separately in #1201.

What remains is a documentation fix to relatedCryptographicAsset:

• The type description was a copy of the securedBy text. It now describes the kind of referenced asset.
• certificate is added to the type examples.
• Grammar fix in the object description.

[bhess]

LGTM, but I'd recommend to rename the title of the PR to reflect the updated scope.

[bhess]

just noticed, the correct spelling in 2.0 is public-key and private-key, respectively.

[Mehrn0ush]

Fixed, Thanks @bhess.

While checking, I found the same old spelling in existing 2.0 test fixtures: four related-asset entries used "type": "publicKey". I updated them to public-key in this PR so the fixtures match the schema examples:

• valid-cryptography-certificate-2.0.json
• valid-cryptography-full-2.0.json
• valid-cryptography-certificate-advanced-2.0.json

type is a free string, so these validated before and still do. The change is for consistency only. No other 2.0 fixture uses the camelCase spelling for this property. If you'd rather keep the fixture change out of this PR, I can drop that commit.