Skip to content

Adding a first draft on handling of digital signatures #21

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
May 28, 2025

Conversation

oej
Copy link
Collaborator

@oej oej commented Jul 13, 2024

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

Feedback is always welcome!

@@ -0,0 +1,108 @@
# Trusting digital signatures in TEA

Software transparency is a lot about trust. Within the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

or set up an internal solution. The issue with that is that external
parties do not automatically trust that internal PKI.

This document outlines a proposal on how to build that trust and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

## Digital signatures

### Digital signatures as specified for CycloneDX
"Digital signatures may be applied to a BOM or to an assembly within a BOM.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I do like detached signatures :-)


## Using Sigstore for signing

Sigstore is an excellent free service for both signing of GIT commits as well
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

@jksolbakken jksolbakken Nov 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

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
Copy link
Collaborator Author

oej commented Aug 5, 2024

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
Copy link
Contributor

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 oej mentioned this pull request Aug 20, 2024
@oej
Copy link
Collaborator Author

oej commented Aug 20, 2024

Moved discussions on PGP to a separate issue

@oej
Copy link
Collaborator Author

oej commented Aug 20, 2024

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

@@ -104,7 +104,7 @@ Append the product part of the TEI to the URI found

- TEI: `urn:tei:uuid:products.example.com:d4d9f54a-abcf-11ee-ac79-1a52914d44b1`
- DNS record: `_tei._tcp.products.example.com`
- URI in DNS: `://www.example.com/transparency/`
- URI in DNS: `https://www.example.com/transparency/`
- URL: `https://www.example.com/transparency/d4d9f54a-abcf-11ee-ac79-1a52914d44b1/`

If no DNS URI records are found the resolution defaults to A and AAAA records.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #64

validated.

Within the
API documents can be signed with an electronic
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

- __Integrity__: Documents dowloaded needs to be the same
as documents published
- __Identity__:
- Customers need to be able to verify the
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines +65 to +77
the current trust anchor APIs. This file is not signed,
that would cause a chicken-and-egg problem. The certificates
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

oej and others added 7 commits May 28, 2025 16:36
Signed-off-by: Olle E. Johansson <[email protected]>
Signed-off-by: Olle E. Johansson <[email protected]>
Co-authored-by: A.J. Stein <[email protected]>
Signed-off-by: Olle E. Johansson <[email protected]>
Signed-off-by: Olle E. Johansson <[email protected]>
Signed-off-by: Olle E. Johansson <[email protected]>
Signed-off-by: Olle E. Johansson <[email protected]>
@oej oej changed the title Draft: Adding a first early draft on handling of digital signatures Adding a first draft on handling of digital signatures May 28, 2025
oej and others added 4 commits May 28, 2025 16:37
Co-authored-by: Paul Horton <[email protected]>
Signed-off-by: Olle E. Johansson <[email protected]>
Co-authored-by: Paul Horton <[email protected]>
Signed-off-by: Olle E. Johansson <[email protected]>
Co-authored-by: Paul Horton <[email protected]>
Signed-off-by: Olle E. Johansson <[email protected]>
Co-authored-by: Paul Horton <[email protected]>
Signed-off-by: Olle E. Johansson <[email protected]>
@oej oej merged commit 61fb70f into CycloneDX:main May 28, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants