Skip to content
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.

Sign up for GitHub

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

Add use case from original use case document to address issue 325 #328

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Add use case from original use case document to address issue 325 #328

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
11248b5
Added signing authenticity use case
rjb4standards Dec 20, 2024
4d02031
Merge pull request #1 from rjb4standards/rjb4standards-patch-1
rjb4standards Dec 20, 2024
1b5e5ec
Followed Steve Recommendation; removed proposed use case
rjb4standards Dec 30, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 16 additions & 7 deletions draft-ietf-scitt-architecture.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -68,6 +68,14 @@ contributor:
contribution: >
Orie contributed to improving the generalization of COSE building blocks and document consistency.

- ins: D. Brooks
name: Dick Brooks
organization: Business Cyber Guardian (TM)
email: [email protected]
country: United States
contribution: >
Dick contributed some software supply chain use cases consistent with US DHS CISA Secure by Design principles and practices

normative:
RFC5280: PKIX
RFC6838:
Expand Down Expand Up @@ -267,7 +275,7 @@ The intention is to identify any security weaknesses or vulnerabilities in the p

Initially, a particular analysis can identify a simple weakness in a software component.
Over a period of time, a statement from a third-party illustrates that the weakness is exposed in a way that represents an exploitable vulnerability.
The producer of the software product provides a statement that confirms the linking of a software component vulnerability with the software product and also issues an advisory statement on how to mitigate the vulnerability.
The producer of the software product provides a statement that confirms the linking of a software component vulnerability with the software product by issuing a product vulnerability disclosure report and also issues an advisory statement on how to mitigate the vulnerability.
At first, the producer provides an updated software product that still uses the vulnerable software component but shields the issue in a fashion that inhibits exploitation.
Later, a second update of the software product includes a security patch to the affected software component from the software producer.
Finally, a third update includes a new release (updated version) of the formerly insecure software component.
Expand All @@ -290,26 +298,26 @@ SCITT provides a standardized way to:

### Promotion of a Software Component by Multiple Entities

A software component (e.g., a library) released by a certain original producer is becoming popular.
The released software component is accompanied by a statement of authenticity (e.g., a detached signature).
A software component (e.g., a library or software product) released by a certain original producer is common practice for both open-source and commercial offerings.
The released software component is accompanied by a statement of authenticity (e.g., an embedded or a detached signature).
Copy link
Collaborator

@SteveLasker SteveLasker Jan 3, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

SCITT doesn't support embedded signatures, as they don't support the multi-party/post-build processes.
Removing the suggestion, and leaving it as a comment

The released software component is accompanied by a statement of authenticity (e.g., a detached signature).

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@SteveLasker you suggest removing embedded signatures. Does this mean that embedded signatures on artifacts are not supported in SCITT?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm suggesting we remove references to embedded signatures as SCITT doesn't know about them.
The content also conflates a few different concepts of attached/detached payloads, referencing an artifact the statement is about, and attached signatures that are not part of the SCITT Architecture.

I'm going to suggest the following change.

SCITT doesn't support embedded signatures, as they don't support the multi-party/post-build processes.

Suggested change
The released software component is accompanied by a statement of authenticity (e.g., an embedded or a detached signature).
The released software component is accompanied by a statement of authenticity.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@SteveLasker Many post build artifacts, like MSI installation packages contain embedded digital signatures. This change seems to allow either/or embedded/detached authenticity evidence.

Over time, due to its enhanced applicability to various products, there has been an increasing amount of multiple providers of the same software component version on the internet.

Some providers include this particular software component as part of their release package bundle and provide the package with proof of authenticity using their own issuer authority.
Some providers include this particular software component as part of their release product package bundle and provide the product package with proof of authenticity using their own issuer authority.
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
Some providers include this particular software component as part of their release product package bundle and provide the product package with proof of authenticity using their own issuer authority.
Some providers include this particular software component as part of their release product/package bundle and provide the package with proof of authenticity using their issuer authority.

Some packages include the original statement of authenticity, and some do not.
Over time, some providers no longer offer the exact same software component source code but pre-compiled software component binaries.
Some sources do not provide the exact same software component, but include patches and fixes produced by third-parties, as these emerge faster than solutions from the original producer.
Due to complex distribution and promotion life-cycle scenarios, the original software component takes myriad forms.

A consumer of a released software wants to:

* understand if a particular provider is actually the original provider or a promoter
* understand if a particular provider is actually the original authorized producer or an alternative party
Copy link
Contributor

Choose a reason for hiding this comment

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

What does authorized mean in the context of all possible subjects of a statement by an issuer? For freely and openly licensed software, there are little or no restrictions on a producer of software, not to speak of public domain work.

Is there alternative wording for authorized? I have thought of it for a little while, but have yet to find alternative wording I could propose. I will think about it some more though.

Copy link
Collaborator

@SteveLasker SteveLasker Jan 3, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

I struggle with Authorized as well, as it's also not clear who is stating who should be "authorized" and to whom?

A consuming company may authorize EntityA, but not EntityB, while another may require a different Entity to produce the same package, such as RedHat or a specific Industry "authorized" endorsement.

Originating could also be questioned.
At the end of the day, the verifier makes a decision which issuers they trust, for a given environment.

Suggested change
* understand if a particular provider is actually the original authorized producer or an alternative party
* understand if a particular provider is a trusted originating producer or an alternative party

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@SteveLasker would it help to replace "authorized" with "legitimate".

People need to be able to determine if an artifact is to be trusted, or not, based on a verifiable method. I'm asserting that the presence of an artifact in a SCITT registry is sufficient to make it trustworthy, but the process used to register an artifact in a SCITT trust registry needs to be able to discern a trustworthy artifact and one that is false, or not trustworthy.

Somehow, the SCITT "solution" needs to be able to discern trusted artifacts from untrusted artifacts and the ability to establish trust in the artifacts supply chain is key to this process. Only trusted artifacts, submitted by trusted parties make their way into a SCITT trust registry, IMO.

Copy link
Collaborator

Choose a reason for hiding this comment

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

How does an entity determine trust?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@SteveLasker I'm hoping the SCITT spec will describe how trust is ascertained before an item is placed into the registry. Then parties can simply trust an artifact because it is in the registry, and has been properly vetted as trustworthy. This is how a "Registry of Deeds" works, which IMO is a good model for a SCITT Trust Registry. Only trusted artifacts can be placed into the registry.

* know if and how the source, or resulting binary, of a promoted software component differs from the original software component
* check the provenance and history of a software component's source back to its origin
* assess whether to trust a promoter or not
* assess whether to trust a component or product based on a downloaded package location and source supplier

SCITT provides a standardized way to:

* reliably discern if a provider is the original producer or is a trustworthy promoter or is an illegitimate provider
* reliably discern if a provider is the original, trusted producer or is a trustworthy alternative provider or is an illegitimate provider
Copy link
Contributor

Choose a reason for hiding this comment

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

Like my previous comment, are there more neutral and perhaps less loaded terms than illegitimate?

* track the provenance path from an original producer to a particular provider
* check the trustworthiness of a provider
* check the integrity of modifications or transformations applied by a provider
Expand All @@ -334,6 +342,7 @@ SCITT provides a standardized way to:
* notify software integrators of vulnerabilities identified during security scans of running software
* provide valid annotations on build integrity to ensure conformance


# Terminology {#terminology}

The terms defined in this section have special meaning in the context of Supply Chain Integrity, Transparency, and Trust, which are used throughout this document.
Expand Down
Loading