Adding a first draft on handling of digital signatures

[oej]

Trying to gather thoughts on digital signatures in the TEA collections and for TEA artefacts.

Feedback is always welcome!

[aj-stein-nist]

Trust is a human determination about software. Is software transparency not about trustworthiness?

[oej]

I will rephrase this... Thanks for the feedback.

[aj-stein-nist]

The above statements imply that the publisher controls one or more pairs of asymmetric keys, but that is not immediately clear from lines 20 to 27. Who is to sign the BOM if the party uploading the BOM or related artifacts is not the original publisher of the software?

(FYI: For this reason, a related IETF standard talks about Issuer as a key role in their architecture; the publisher of software is not always the Issuer as defined by the IETF SCITT WG, and vice versa.)

[oej]

I think signing has to be optional. But the question of a third party that publishes something is a bit out of scope for our work, while I understand it is part of SCITT. I will consider this and see what can be done.

[aj-stein-nist]

Is the intention here that you would have digital signatures for individual inline assemblies and the overall package that composes them? I tried reviewing the CycloneDX documents and this specification but that sounds like it can get complex very quickly.

[oej]

I just quoted the text from the CycloneDX specs. Agree that it may feel messy, but it may have a point as you can include attestations, patches and much more in a CycloneDX BOM.

[oej]

Personally I do like detached signatures :-)

[aj-stein-nist]

Is it the responsibility of the Transparency API described in this specification to compute and verify such hashes from external sources like Sigstore and/or elsewhere?

[oej]

That is a good question. I think validation primarily is when someone downloads artefacts. But it can of course also apply to publication - a server implementation may not accept signed documents that the server can not validate. Good question.

[jksolbakken]

With OCI (Docker) images the producer generates and uploads the signature to the registry alongside the image artifact using the cosign utility. The consumer also uses cosign to verify the signature against the Sigstore transparency log. It is not a super-streamlined experience, but it beats fiddling with PGP any day 😄

[ppkarwasz]

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.

[oej]

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.

[ppkarwasz]

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.

[oej]

Moved discussions on PGP to a separate issue

[oej]

Added a clarification that digital signatures are optional. It may not be in future versions of the API, but we have to start somewhere.

[madpah]

See #64

[madpah]

Suggested change

	API documents can be signed with an electronic
	API, documents can be signed with an electronic

[madpah]

Suggested change

	- Customers need to be able to verify the
	- Customers need to be able to verify the identity of the

[ppkarwasz]

This file is not signed, that would cause a chicken-and-egg problem.

Should we exclude à priori the signing of trust anchors? In the future they might be signed by some authority, e.g. regulators.

[0x73746F66]

A TEA authority (would there be one? Would TEA server operators all be a trust anchor?), the TEA authority should hold a trust anchor's private key, that is used as a key signing key KEK. Then the regulators can provide key material (CSR) to specify the setup for the TEA signing PKI - but, in TEA it might be better to do more modern signature than PKI such as how Sigstore do keyless signing IMHO.
But yes, AU has a regulator called APRA that issue banking licenses to any deposit taking orgs, and they expect the org to provide key material even if there is better options than PKI (ask me how I know... I was involved in the first global AWS Banking material workload)