Add use case from original use case document to address issue 325 #328
Conversation
Added signing authenticity use case
rjb4standards
requested review from
henkbirkholz,
ad-l,
fournet,
yogeshbdeshpande,
SteveLasker,
JAG-UK,
OR13 and
aj-stein-nist
as code owners
rjb4standards
changed the title
Also added proposed language teh the use cases present in the architecture document
| 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| * 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 |
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
How does an entity determine trust?
There was a problem hiding this comment.
@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.
|
|
||
| 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 |
There was a problem hiding this comment.
Like my previous comment, are there more neutral and perhaps less loaded terms than illegitimate?
|
AJ, I'm open to other terminology that will emphasize the need to confirm a trusted party as producer and signer of digital objects. Perhaps the term legitimate could replace authorized. |
| 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). |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
@SteveLasker you suggest removing embedded signatures. Does this mean that embedded signatures on artifacts are not supported in SCITT?
There was a problem hiding this comment.
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.
| 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. |
There was a problem hiding this comment.
@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. |
There was a problem hiding this comment.
| 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. |
Added one use case from original use case document: Signing certificate authenticity use case