As far as I understand just getting the signature with SignotaurTool params --uf and -dt is not enough as the json needs to be canonicalised as well (JCS / RFC 8785).
Has anybody done that successfully or got cyclonedx_cli to work with SignoTaur?
Or is a feature planned in this regard? SBOMs have been a hot topic for a while due to EU CRA.
Hi @msohn,
Welcome to the forum, and thanks for your questions.
JCS canonicalisation is only needed for a JSF signature embedded in the BOM. SignotaurTool does not currently produce JSF signatures, but it can sign a JSON BOM without modifying it by creating a detached PKCS#7/CMS signature:
signotaurtool sign --detached -c "Your Cert" bom.cdx.json
This creates bom.cdx.json.p7s, which can be verified with SignotaurTool or openssl cms -verify -inform DER -in bom.cdx.json.p7s -content bom.cdx.json -binary -CAfile chain.pem.
You can drop --uf: it is not needed with --detached. Using --uf UseCMSSigning without --detached would replace the JSON with a PKCS#7 blob.
As for direct integration with cyclonedx-cli, it cannot currently sign JSON BOMs. Version 0.33.1 reports:
Only XML BOMs are currently supported for signing.
It also signs using a local PEM key and has no mechanism for delegating signing to a remote service or HSM, so there is no direct Signotaur integration point.
If CycloneDX XML is an option, signotaurtool sign --format xades -c "Your Cert" bom.xml creates an embedded signature that cyclonedx verify all accepts; we have tested this with version 0.33.1. However, CycloneDX verifies it against a separately supplied RSA public key and does not validate the certificate chain or check revocation. If you need certificate-based trust validation, the detached CMS signature is a better fit.
Native JSF signing is not currently on our roadmap, although it is feasible. If the lack of native JSF signing is blocking your CRA compliance work, please let us know so we can take that into account when prioritising it.
Thank you for your extensive and highly informative reply - very much appreciated.
Am I correct to assume that for CycloneDX XML signing with xades format, we would need to upgrade to Enterprise? We’re currently still on 1.x, so this is something we would need to consider.
Speaking of document signing, have you considered offering a client app for macOS? Since we’re also building on macOS, we naturally need to assemble and sign an SBOM on that platform too.
Hi @msohn,
Upgrading to v2.1 does not require an Enterprise licence, but XAdES document signing does. Once you’ve upgraded, you can request a 14-day Enterprise trial if you’d like to test the feature first.
As for macOS, the SignotaurTool client is built on a cross-platform framework, but currently relies on Windows APIs for some functionality, particularly Authenticode signing. It would be feasible to separate the document-signing functionality from those Windows-specific parts and provide a macOS client. That’s something we’d certainly consider if there is demand, although it isn’t currently on our roadmap.
Thanks once again for the clarifications. I’ll make sure to reply here if we end up having demand for either native JSF signing or the macOS client.