CycloneDX
Draft: Adding a first early draft on handling of digital signatures
Trying to gather thoughts on digital signatures in the TEA collections and for TEA artefacts.
Feedback is always welcome!
I like the way this proposal aims to automate the verification of signatures of published artifacts. We regularly receive requests from users that wish to verify the artifact signatures we publish on Maven Central.
I have however a couple of concerns:
- CycloneDX signatures are a new mechanism to sign artifacts and currently most SBOMs don't have them. On the other hand I found GPG signatures on Maven Central going back as far as 2007 at least. We should probably also publish trust anchors for these legacy mechanisms, which would allow us to verify the entire software stack of an application without waiting for an SBOM signature of each dependency.
- Should the API distribute only its own trust anchors or also the trust anchors of its suppliers (using some namespacing mechanism? The latter seems like a better choice, since it will create a web-of-trust that is more difficult to compromise.
Supporting GPG signatures is good for backwards compatibility but do we want to put that implementation burden on new implementations, which this will be? Food for thought.
Being able to add upstream trust anchors is a very good idea.
Supporting GPG signatures is good for backwards compatibility but do we want to put that implementation burden on new implementations, which this will be? Food for thought.
The availability of PGP trust anchors is the main reason PyPI removed signatures from their repository: https://blog.pypi.org/posts/2023-05-23-removing-pgp/ On the other hand Maven Central requires PGP signatures for all published artifacts: https://central.sonatype.org/publish/requirements/
I don't think we should require the support of the OpenPGP format, but we might allow users to publish the public keys as X509 certificates and mark their usage as "Maven only", "PyPI only", etc. The main use case would be to allow a user to verify the authenticity of the sub-components of an ACME Miracle Server product. If Dependency Track can verify that a sub-component comes from an upstream supplier without modifications, it can provide security alerts before those alerts propagate to the ACME API server.
Added a clarification that digital signatures are optional. It may not be in future versions of the API, but we have to start somewhere.