search

ietf-scitt / draft-birkholz-scitt-architecture

A specification including, problem statement, use cases, requirements, and architectural constituents for a Transparency Service in support of Supply Chain Integrity, Transparency, and Trust
Other
14 stars 11 forks source link

Converge Claim and Statement #34

Closed SteveLasker closed 1 year ago

SteveLasker commented 2 years ago

At IETF-115, discussions involved:

Existing Standards Terminology

Proposal

Claim conflicts with RATS and W3C

Comparison of terms across orgs as the object changes state:

Instead of transitioning from statement to claim to transparent claim, what if we used statement as the base concept:

kaywilliams commented 2 years ago

Agree with this proposal. It is conceptually simpler to understand that an underlying item ('statement') transitions through states (unsigned, signed, transparent). When it comes to terminology lets aim for the KISS principle.

rjb4standards commented 2 years ago

What are the constraints surrounding statement and claim? How are they distinguished?

SteveLasker commented 1 year ago

@rjb4standards, using the picture @OR13 provided above,

All we're proposing here is converging terminology, as changing the terminology from statement to claim infers it's more than furthering the statement along the workflow

rjb4standards commented 1 year ago

Thanks Steve. Assuming a consumer only has the "artifact" in their possession, i.e. a software package downloaded from GitHub, how could they verify the trustworthiness of the package, having nothing more than the package/artifact itself in their possession, and knowledge of a SCITT Trusted Registry Registry service.

This is the scenario we face every day in the SW supply chain, within the consumer role.

This is the scenario I'm hoping SCITT will provide a solution, or RATS - it doesn't really matter to me if it's RATS or SCITT - I care about the functionality.

SteveLasker commented 1 year ago

@rjb4standards, those are great questions. I'd just suggest we focus on the convergence of the terminology here. For the purposes of this issue, the issuer creates a statement about an artifact. It gets signed (signed statement), and placed on the ledger (transparent statement). If the user simply wants to get a notarized statement that the net-monitor:v1 software was issued by "wabbit-networks", the user can submit a statement to the registry that it was signed by wabbit-networks. There's no "evidence" or additional information provided, yet. It's simply a notarized statement that wabbit-networks submitted the artifact.

rjb4standards commented 1 year ago

Steve, will SCITT provide a consumer the ability to query the web registry for a notarized statement for an artifact, having nothing more than the artifact in their possession?

I download a program from GitHub, and want to "ask SCITT" is this program trustworthy? This is the scenario that is prevalent across the supply chain today.

SteveLasker commented 1 year ago

Another great question, which we've been saying "yes", but "how" is the open question. But, I'd also ask we focus on the terminology issue here and open those discussions in the IETF alias.

rjb4standards commented 1 year ago

ok.

OR13 commented 1 year ago

Given the confusion with RATs I suggest we avoid reusing "claim" and we make SCITT apply to statements, with explanatory text under each definition, relating the concept to other standards.

For example:

statement

signed statement

transparent statement

rjb4standards commented 1 year ago

Orie, here is an example flow from the software supply chain today:

  1. An artifact is born, i.e. app in app store, SBOM, NIST VDR, etc.
  2. Consumer wants to know, is artifact trustworthy; check the trust registry for trust declarations for artifact
  3. Assuming a process will exist to populate the trust registry with trust declarations for the artifact
  4. Process will need a "trusted party" to determine that artifact is trustworthy, using a defined process and criteria that are intended to validate/confirm the trustworthiness of an artifact based on evidence collected/produced.
  5. Trusted party determines that a trust declaration is warranted, based on the defined process and criteria
  6. Trusted party requests registration of a trust declaration in the trusted registry for the now trusted artifact
  7. Registration is confirmed in the trust registry via a positive acknowledgement that the entry is stored in the registry
  8. Trusted party that performed the process resulting in the registration of a trust declaration informs the artifact owner that the artifact has been registered as trustworthy in the SCITT trust registry
  9. Artifact owner informs interested parties on how to check a SCITT trust registry for trustworthiness of an artifact
  10. Interested parties query the SCITT Trust Registry for trust declarations for an artifact, using information provided by the artifact owner
  11. Upon receiving confirmation from the Trust Registry Service that an artifact is listed as trustworthy the party with an interested in the artifact proceeds to implement/apply the artifact in its intended role

It would help me "connect the dots" if you could identify the items listed/used in the flow above using the proposed terminology. Thanks... Dick

OR13 commented 1 year ago

@rjb4standards all of those are statements, that an issuer might take responsibility for by making signed statements, and that an interested supply chain party might then make transparent by submitting to a transparency service and obtaining a receipt.

While we are focused on software supply chain use case, there is no reason to look at anything other than the "header" for IETF... we are payload agnostic.

If you have an artifact, or metadata about an artifact, you might ask a transparency service or a database in front of one, "what signed statements or transparent statements do you have that are related to my artifact or metadata".

That query would in turn be translated into a format that processed the IETF standard formats for "signed statement" or "transparent statement".

In the context of IETF work, we are interested in the following:

In the context of the broader community, we are interested in the following:

I suspect most of your questions have more to do with how the specifications will be deployed and used, and less to do with the specific requirements embedded in the specification, but I do think you are offering "requirements" which are accounted for in the slides presented at IETF 115 under the architecture section... In particular the slide describing "what is a claim" and the one describing "what is a receipt".

We've not discussed query formats for specific payload shapes in depth yet.

rjb4standards commented 1 year ago

I believe you are correct Orie: I do think you are offering "requirements" I think this list represents "minimum requirements" for a minimum viable SCITT standard for software supply chain verification of trust for an

letmaik commented 1 year ago

Quoting Orie:

What is the shape of a "transparent statement" or "receipt".

"transparent statement" != "receipt", but rather "transparent statement" = "signed statement" + "receipt".

Also, note that nothing is said about how "signed statement" and "receipt" are transported -- might be bundled together (e.g., using an unprotected header parameter in the "signed statement"), might be two files on disk, or something else entirely.

If we're clear on the above, then I'm in favor of the new terminology.

If anyone has concerns, please speak up.

rjb4standards commented 1 year ago

Is the "receipt" component contained in a "transparent statement" a signed object, i.e. "transparent statement" = "signed statement" + signed(receipt)

Is a transparent statement digitally signed?

yogeshbdeshpande commented 1 year ago

I prefer "Claim" over "Signed Statement" as it leaves flexibility of defining properly what a claim is: Today it is a Signed Statement presumably from one signer? Tomorrow it could be multiple signers vouching for the same Artifact thus it is "Multi Signed Statement". I am not too concerned about the overlap with RATS terminology so long as we define that within SCITT Ecosystem a Claim is a Signature of Issuer on the given Statement about an Artifact.

rjb4standards commented 1 year ago

What is an SBOM considered in this taxonomy? A claim, a statement or an artifact which a claim/statement refers to?

yogeshbdeshpande commented 1 year ago

I think we are digressing from the core point of terminology here!

Depends on the Use Case: In Use Case 1: SBOM goes into registry!

SBOM is a Statement about an Artifact (Software).

When the issuer would Sign a SBOM before submitting it to the Registry, it will become a Claim.

What the Registry returns is a Transparent Claim = Signed Claim + Receipt

rjb4standards commented 1 year ago

FYI: Some SBOM's can be quite large, i.e. 2 MB of text.

yogeshbdeshpande commented 1 year ago

Yes, then you need Use Case 2: User Makes a statement about SBOM. Here SBOM itself is Artifact! The Statement may contain details about SBOM. ( What is SBOM size, what is its hash, who is the owner etc). When user signs the Statement (about SBOM) it becomes a Claim. Claim enters the SCITT Registry and becomes a Transparent Claim.

rjb4standards commented 1 year ago

Yogesh,

How will trust be assured if the user that creates an artifact, then makes a statement about the artifact, which becomes a claim that gets placed into a registry, becoming a "transparent claim" - this seems to be missing a critical step, a trusted objective party that assesses the statement for trustworthiness when deciding to create a claim that goes into the registry resulting in a "Transparent Claim" that end users can retrieve to verify the trustworthiness of an artifact, i.e. SBOM in this case.

yogeshbdeshpande commented 1 year ago

Yogesh,

How will trust be assured if the user that creates an artifact, then makes a statement about the artifact, which becomes a claim that gets placed into a registry, becoming a "transparent claim" - this seems to be missing a critical step, a trusted objective party that assesses the statement for trustworthiness when deciding to create a claim that goes into the registry resulting in a "Transparent Claim" that end users can retrieve to verify the trustworthiness of an artifact, i.e. SBOM in this case.

The Statement including the SBOM Details does not necessarily be only about SBOM, but the statement is open enough to list the details about the Artifact also, which it links to SBOM. So basically how the user constructs the Statement is entirely up to the Statement owner. Perhaps we should discuss what the Statements should look like but definitely we are digressing here where the original issue is about the terminologies!

OR13 commented 1 year ago

reminder to read the drafts:

When we discuss terms, we are only discussing changes to these documents.

The goal of discussing on Github issues to gather consensus so that a pull request can be opened to make changes to these documents.

We are talking about adjusting this section of content:

https://ietf-scitt.github.io/draft-birkholz-scitt-architecture/draft-birkholz-scitt-architecture.html#name-terminology

SteveLasker commented 1 year ago

These are all great discussions to create clarity for the e2e. Much of what @rjb4standards is discussing around larger SBOMs being a statement, is the statement by reference conversations. Essentially, yes an SBOM is a statement, we're just discussing if the statement stores a hash of the SBOM that's stored alongside the ledger. However, these are orthogonal to the question in this issue :)

I'd suggest it's really important for us to simplify terms, not conflate confusion with RATS, which is very close to what we're doing, and move onto triaging all the other topics, such as #33, #35, #28, #36

In the spirit that we can't make everyone happy, can we get a thumbs up/down for "converging claims to statements".

Based on the tally, we can decide if we need more time on this, or we can move onto the other issues.

kaywilliams commented 1 year ago

👍🏼

rjb4standards commented 1 year ago

Steve, in my world an SBOM is an artifact and the SBOM owner makes a "statement" indicating the SBOM artifact is trustworthy. A 3rd party examines the Statement and decides to issue a claim indicating that the SBOM artifact is indeed trustworthy and places a "Transparent Claim" into the registry indicating that the SBOM artifact is trustworthy.

At some later time a consumer acquires the SBOM artifact and want to know, is this artifact trustworthy. A query is issued to the Transparency Service based on information about the artifact, i.e. SHA-256 hash value + SKID used to sign the artifact. Transparency Service returns a set of transparent claims in the registry for the SBOM artifact in question.

NOTE: I use SBOM here, but this process should work for ANY artifact that a consumer wants to know, "Is artifact X trustworthy?"

If this scenario is supported within SCITT, then I'm good. Please correct me if I'm off-base in believing this scenario will be supported by SCITT. NOTE: In this scenario an SBOM is NOT a Statement, it is an artifact. ANY artifact that a consumer can acquire, and wants to check it's trustworthiness should be supported by SCITT, IMO

SteveLasker commented 1 year ago

@rjb4standards, we've been discussing "Artifact" as the root object by which we're creating statements/claims, which may be SBOMs, Vex, VD, etc.

While an SBOM itself can also be an "artifact", I'd suggest we find another category. I've been using the term "evidence" to support information about an Artifact (see Artifacts, Claims Evidence, which needs updating.

Using your terminology:

an SBOM is an artifact and the SBOM owner makes a "statement" indicating the SBOM artifact is trustworthy.

I'd suggest a minor tweak:

An SBOM owner submits a signed statement to the Transparency Service (see #38 for more terminology). If the Transparency Service returns a receipt, it's considered it came from a verified identity.

At IETF, we did discuss the challenges with putting SBOMs directly on the ledger, which is covered in #35. The end result would be the same. Meaning, you would still get the SBOM back, but it may come as link from a Transparency Service's associated storage, or an external reference if stored elsewhere.

Does that help?

rjb4standards commented 1 year ago

Steve,Is this accurate:An ARTIFACT is the subject of a TRANSPARENT CLAIM listed in the TRUST REGISTRY of a TRANSPARENCY SERICEConsumers query  aTRUST SERVICE for TRANSPARENCY CLAIMS for ARTIFACTS in their possessio. Im trying to figure out the bookennds. Sent from my iPhoneOn Nov 17, 2022, at 7:45 PM, Steve Lasker @.***> wrote: @rjb4standards, we've been discussing "Artifact" as the root object by which we're creating statements/claims, which may be SBOMs, Vex, VD, etc. While an SBOM itself can also be an "artifact", I'd suggest we find another category. I've been using the term "evidence" to support information about an Artifact (see Artifacts, Claims Evidence, which needs updating. Using your terminology:

an SBOM is an artifact and the SBOM owner makes a "statement" indicating the SBOM artifact is trustworthy.

I'd suggest a minor tweak:

An SBOM owner submits a signed statement to the Transparency Service (see #38 for more terminology). If the Transparency Service returns a receipt, it's considered it came from a verified identity.

At IETF, we did discuss the challenges with putting SBOMs directly on the ledger, which is covered in #35. The end result would be the same. Meaning, you would still get the SBOM back, but it may come as link from a Transparency Service's associated storage, or an external reference if stored elsewhere. Does that help?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

rjb4standards commented 1 year ago

Let me correct the record, and mis-spellings while using my cell phone

Is this accurate:

An ARTIFACT is the subject of a TRANSPARENT CLAIM listed in the TRUST REGISTRY of a TRANSPARENCY SERVICE

Consumers query a TRANSPARENCY SERVICE for TRANSPARENT CLAIMS for ARTIFACTS in their possession.

I’m trying to figure out the bookends in the SCITT process.

Thanks,

Dick Brooks

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

https://reliableenergyanalytics.com/products Never trust software, always verify and report! ™

http://www.reliableenergyanalytics.com/ http://www.reliableenergyanalytics.com

Email: @.> @.

Tel: +1 978-696-1788

From: Dick Brooks @.> Sent: Thursday, November 17, 2022 8:43 PM To: ietf-scitt/draft-birkholz-scitt-architecture @.> Cc: ietf-scitt/draft-birkholz-scitt-architecture @.>; Dick Brooks @.>; Mention @.***> Subject: Re: [ietf-scitt/draft-birkholz-scitt-architecture] Converge Claim and Statement (Issue #34)

Steve,

Is this accurate:

An ARTIFACT is the subject of a TRANSPARENT CLAIM listed in the TRUST REGISTRY of a TRANSPARENCY SERICE

Consumers query aTRUST SERVICE for TRANSPARENCY CLAIMS for ARTIFACTS in their possessio.

Im trying to figure out the bookennds.

Sent from my iPhone

On Nov 17, 2022, at 7:45 PM, Steve Lasker @.***> wrote:



@rjb4standards https://github.com/rjb4standards , we've been discussing "Artifact" as the root object by which we're creating statements/claims, which may be SBOMs, Vex, VD, etc.

While an SBOM itself can also be an "artifact", I'd suggest we find another category. I've been using the term "evidence" to support information about an Artifact (see Artifacts, Claims Evidence https://scitt.io/components/artifacts--claims-evidence.html , which needs updating.

Using your terminology:

an SBOM is an artifact and the SBOM owner makes a "statement" indicating the SBOM artifact is trustworthy.

I'd suggest a minor tweak:

An SBOM owner submits a signed statement to the Transparency Service (see #38 https://github.com/ietf-scitt/draft-birkholz-scitt-architecture/issues/38 for more terminology). If the Transparency Service returns a receipt, it's considered it came from a verified identity.

At IETF, we did discuss the challenges with putting SBOMs directly on the ledger, which is covered in #35 https://github.com/ietf-scitt/draft-birkholz-scitt-architecture/issues/35 . The end result would be the same. Meaning, you would still get the SBOM back, but it may come as link from a Transparency Service's associated storage, or an external reference if stored elsewhere.

Does that help?

— Reply to this email directly, view it on GitHub https://github.com/ietf-scitt/draft-birkholz-scitt-architecture/issues/34#issuecomment-1319404328 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFI3NEMZXU6EWN4U3VPGHLWI3GUDANCNFSM6AAAAAARYQYTBM . You are receiving this because you were mentioned.Message ID: @.***>

SteveLasker commented 1 year ago

Yup, that would do it. Of course, the terminology for “transparent claim” or “transparent statement” is the topic of this issue.

rjb4standards commented 1 year ago

Correcting the record for spelling mistakes and other ambiguities....

An ARTIFACT is the subject of a TRANSPARENT CLAIM listed in the TRUST REGISTRY of a TRANSPARENCY SERVICE

Consumers query a TRANSPARENCY SERVICE for TRANSPARENT CLAIMS for ARTIFACTS in their possession.

I'm trying to figure out the bookends.

yogeshbdeshpande commented 1 year ago

@SteveLasker to move this to new repository, tracking the entire history

SteveLasker commented 1 year ago

Closing, as this has been copied over to https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/8