search

IBM / CBOM

Cryptography Bill of Materials
Apache License 2.0
48 stars 6 forks source link

curves: OIDs instead of enum? #28

Closed GeroDittmann closed 2 months ago

GeroDittmann commented 10 months ago

cryptoProperties (v1.1) -> algorithmProperties -> curve is proposed as an enum. This would require an update to the CBOM schema for every new curve. Why not just use OIDs?

I went over the proposed enum and found OIDs for every curve (some of which are redundant) except BLS12-XXX, FourQ and the Barreto-Naehrig curves. The following table shows the findings: ellipticCurvesOIDs.xlsx

bhess commented 10 months ago

Thanks for the summary with the OIDs! Avoiding the enum would make things more extensible. However, BLS could be useful, they are used e.g. in Ethereum2. In the CycloneDX CBOM workstream the suggestion was to move to using URNs instead of enums to ensure better extensibility.

GeroDittmann commented 10 months ago

URNs would be super-set to OIDs, thanks to urn:oid:.... Would that help with the missing curves, i.e., are there non-OID URNs for them?

The more options the standard grants, the higher the risk of redundant, non-canonical IDs, making it harder to find any specific curve. (One would have to look for all possible IDs.)

Maybe use oid: and other: prefixes in the value field to make it clear that OIDs should be used where possible but allow non-OID'ed curves to be specified. The spec could give values for the missing curves, e.g., other:BLS12-377 etc. other:bn158 etc. other:FourQ These indeed seem to be the common notations, also according to https://neuromancer.sk/std/

bhess commented 2 months ago

Closing with the upstream to CycloneDX 1.6.