Draft: Adding a first early draft on handling of digital signatures #21

oej · 2024-07-13T11:50:13Z

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

Feedback is always welcome!

Signed-off-by: Olle E. Johansson <[email protected]>

signatures/signature.md

aj-stein-nist · 2024-07-30T16:51:24Z

signatures/signature.md

@@ -0,0 +1,108 @@
+# Trusting digital signatures in TEA
+
+Software transparency is a lot about trust. Within the


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

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

aj-stein-nist · 2024-07-30T16:53:47Z

signatures/signature.md

+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


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

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 · 2024-08-02T19:31:58Z

signatures/signature.md

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


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.

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.

Personally I do like detached signatures :-)

aj-stein-nist · 2024-08-02T19:33:33Z

signatures/signature.md

+
+## Using Sigstore for signing
+
+Sigstore is an excellent free service for both signing of GIT commits as well


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?

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.

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 · 2024-08-05T07:09:06Z

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 · 2024-08-05T07:39:04Z

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 · 2024-08-05T08:43:26Z

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.

Co-authored-by: A.J. Stein <[email protected]> Signed-off-by: Olle E. Johansson <[email protected]>

oej · 2024-08-20T07:15:05Z

Moved discussions on PGP to a separate issue

Signed-off-by: Paul Horton <[email protected]>

Signed-off-by: Olle E. Johansson <[email protected]>

…ference Type Closes CycloneDX#23 Signed-off-by: Olle E. Johansson <[email protected]>

Signed-off-by: Olle E. Johansson <[email protected]>

Based on discussions in CycloneDX#24 there is a need to add use cases documentation for various deliverables that need a TEI Signed-off-by: Olle E. Johansson <[email protected]>

Signed-off-by: Olle E. Johansson <[email protected]>

oej · 2024-08-20T08:02:22Z

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 · 2024-11-12T14:08:31Z

discovery/readme.md

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


madpah · 2024-11-13T08:57:12Z

signatures/signature.md

+validated.
+
+Within the
+API documents can be signed with an electronic


Suggested change

API documents can be signed with an electronic

API, documents can be signed with an electronic

madpah · 2024-11-13T08:58:36Z

signatures/signature.md

+
+Within the
+API documents can be signed with an electronic
+signature. CycloneDX boms supports signatures within


Suggested change

signature. CycloneDX boms supports signatures within

signature. CycloneDX Documents support [signatures](https://cyclonedx.org/use-cases/#authenticity) within

madpah · 2024-11-13T08:58:48Z

signatures/signature.md

+Within the
+API documents can be signed with an electronic
+signature. CycloneDX boms supports signatures within
+the JSON file, but other artefacts may need external


Suggested change

the JSON file, but other artefacts may need external

the JSON and XML files, but other artefacts may need external

madpah · 2024-11-13T08:59:47Z

signatures/signature.md

+the JSON file, but other artefacts may need external
+signature files, a detached signature.
+
+- __Integrity__: Documents dowloaded needs to be the same


Suggested change

- __Integrity__: Documents dowloaded needs to be the same

- __Integrity__: Documents dowloaded must be the same

madpah · 2024-11-13T09:00:21Z

signatures/signature.md

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


Suggested change

- Customers need to be able to verify the

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

madpah · 2024-11-13T09:02:49Z

signatures/signature.md

+## API trust
+
+The TEA API is built on the HTTP protocol with TLS encryption
+and authentication, using the https:// URL scheme.


Suggested change

and authentication, using the https:// URL scheme.

and authentication, using the `https://` URL scheme.

madpah · 2024-11-13T09:05:44Z

signatures/signature.md

+PEM-encoded certificates in one single text file.
+
+The TEA API has a `/trust-anchors/` API that will download
+the current trust anchor APIs. This file is not signed,


the current trust anchor APIs. This file is not signed,

Is APIs the correct word here @oej ?

Adding a first early draft on handling of digital signatures

cbf1e8c

Signed-off-by: Olle E. Johansson <[email protected]>

oej force-pushed the sign-arch branch from 3181620 to cbf1e8c Compare July 13, 2024 11:51

oej added 2 commits July 13, 2024 17:52

Fix typo

2449d22

Signed-off-by: Olle E. Johansson <[email protected]>

Adding some text on sigstore

8347261

Signed-off-by: Olle E. Johansson <[email protected]>

aj-stein-nist reviewed Aug 2, 2024

View reviewed changes

Update signatures/signature.md

6b6fd68

Co-authored-by: A.J. Stein <[email protected]> Signed-off-by: Olle E. Johansson <[email protected]>

oej mentioned this pull request Aug 20, 2024

Support for PGP signatures #31

Open

madpah and others added 9 commits August 20, 2024 09:21

fix: typo in Discovery readme.md

8331716

Signed-off-by: Paul Horton <[email protected]>

collection: Adding a first description

038decb

Signed-off-by: Olle E. Johansson <[email protected]>

Update after discussion with Anthony

aeb73df

Signed-off-by: Olle E. Johansson <[email protected]>

Collection: Adding artifact category pointing to CycloneDX externalRe…

69cb947

…ference Type Closes CycloneDX#23 Signed-off-by: Olle E. Johansson <[email protected]>

Collection: Clarify that order has no significance

dfc425d

Signed-off-by: Olle E. Johansson <[email protected]>

Adding presentations

d5a72d2

Signed-off-by: Olle E. Johansson <[email protected]>

TEA use cases: Adding use cases for products

010a35f

Based on discussions in CycloneDX#24 there is a need to add use cases documentation for various deliverables that need a TEI Signed-off-by: Olle E. Johansson <[email protected]>

Signature: Lint fixes

21dae08

Signed-off-by: Olle E. Johansson <[email protected]>

Cleaning up text

51ca711

Signed-off-by: Olle E. Johansson <[email protected]>

madpah reviewed Nov 13, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Draft: Adding a first early draft on handling of digital signatures #21

Draft: Adding a first early draft on handling of digital signatures #21

oej commented Jul 13, 2024 •

edited

Loading

aj-stein-nist Jul 30, 2024

oej Aug 20, 2024

aj-stein-nist Jul 30, 2024

oej Aug 20, 2024

aj-stein-nist Aug 2, 2024

oej Aug 20, 2024

oej Aug 20, 2024

aj-stein-nist Aug 2, 2024

oej Aug 20, 2024

jksolbakken Nov 25, 2024 •

edited

Loading

ppkarwasz commented Aug 5, 2024

oej commented Aug 5, 2024

ppkarwasz commented Aug 5, 2024

oej commented Aug 20, 2024

oej commented Aug 20, 2024

madpah Nov 12, 2024

madpah Nov 13, 2024

madpah Nov 13, 2024

madpah Nov 13, 2024

madpah Nov 13, 2024

madpah Nov 13, 2024

madpah Nov 13, 2024

madpah Nov 13, 2024

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

		Software transparency is a lot about trust. Within the


		## Using Sigstore for signing

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

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

	signature. CycloneDX boms supports signatures within
	signature. CycloneDX Documents support [signatures](https://cyclonedx.org/use-cases/#authenticity) within

	the JSON file, but other artefacts may need external
	the JSON and XML files, but other artefacts may need external

	- __Integrity__: Documents dowloaded needs to be the same
	- __Integrity__: Documents dowloaded must be the same

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

	and authentication, using the https:// URL scheme.
	and authentication, using the `https://` URL scheme.

Draft: Adding a first early draft on handling of digital signatures #21

Are you sure you want to change the base?

Draft: Adding a first early draft on handling of digital signatures #21

Conversation

oej commented Jul 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jksolbakken Nov 25, 2024 • edited Loading

Choose a reason for hiding this comment

ppkarwasz commented Aug 5, 2024

oej commented Aug 5, 2024

ppkarwasz commented Aug 5, 2024

oej commented Aug 20, 2024

oej commented Aug 20, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oej commented Jul 13, 2024 •

edited

Loading

jksolbakken Nov 25, 2024 •

edited

Loading