###### tags: `scitt`
# SCITT: IETF 115 Notes
## Saturday, 5th November
Note taker: Maik
- Everyone can make claims about any subject.
- If there is no claim from a vendor, then the consumer should better make their own claim, e.g. when consuming firmware in a cloud.
- Legal: Need to protect yourself. How can protect from vendor-injected malware, since vendor doesn't want to make claims?
- Ask another party to make legal claims about that artifact.
- Antoine: Supporting material
- Orie: I don't like that
- No one agrees what evidence is
- Sylvan: better term: "supporting data"
- Orie: W3C defines "evidence" as signed statements that an issuer evaluates before issuing claims [NOTE: They are not separately signed]
- Orie: Verifiable Credential requires spec implementers to understand what evidence means
- agreement that we don't need to introduce "evidence" as concept
- do we care about huge statements?
- Steve: how can we set expections? how do we say that the email body should be relatively small compared to the attachments?
- Orie: IETF is not the space to define this
- Steve: how do we make things interoperable though?
- by defining good content types
- lots of talk about content addressable identifiers
- location hints with content addressable identifier
- are there standards on payloads that are just the content addressable identifiers? JSON? ...
- boundaries of SCITT, how does querying work practically?
Henk is back.
Some scribbles on content-addressed content, and whether SCITT should be restricted to it:
Option 1 - use cty only:
cty = "application/spdx"
cty = "application/scitt.content-addressed+json"
Option 2 - always by ref, special header params:
refhash = "abcd"
refcty = "application/spdx"
## Sunday 6th November
What are the existing concepts
To start, we'll avoid specific terms, so we can define things abstractly, and then find terms we can assign. The goal is to leverage existing IETF and/or W3C definition and terms, or at least not conflict and cause confusion with existing terms.
- We're adding information about software (versioned) and hardware items. Hardware items need to account for specific instances (serial numbers)
- All things must be signed to assure there's known identity associated with each thing.
Claim conflicts with RATS and W3C
Comparison of terms across orgs as the object changes state:
- Signed Statment
- Transpartent Statement
### Existing Standards Terminology
- [IETF: Remote Attestation Procedures Architecture (RATS)](https://www.ietf.org/archive/id/draft-ietf-rats-architecture-22.html#name-artifacts)
- [IETF: SCITT Architecture](https://ietf-scitt.github.io/draft-birkholz-scitt-architecture/draft-birkholz-scitt-architecture.html#name-terminology)
- [IETF: RFC7519](https://www.ietf.org/archive/id/draft-ietf-rats-architecture-22.html#RFC7519)
## SCITT Terminology
the process of submitting a *"Claim"* to a Transparency Service, applying its registration policy, storing it in the Registry, producing a Receipt, and returning it to the submitter.
- **Registration Policy**:
the pre-condition enforced by the TS before registering a Claim, based on its Envelope (notably the identity of its Issuer) and on prior claims already in the Registry.
### Indexing Pivots
How may a SCITT instnace index the ledger to support querying?
- Different artifacts, with continuous versions (net-monitor:v1, v2, v2.1, v3...). There are multiple versioned artifacts aggregator:v1, v1.1, v2
- Different issuers make claims/statements about the artifacts
- Based on an artifact, I want to know what versions are available
- Based on a versioned artifact, I want all statements made
- Based on a versioned artifact, I want to filter by issuers
- Based on a versioned artifact, I want to query specific attributes, filtered by one or more issures
### Data Payload
- Differentiate between common content across all content types going into the ledger, from unique data elements across specific content types.
- A SCITT instance owner would have the option for how large content (the attachments) are persisted enabling the ledger to be lightweight data to enable storage over 10-50 years, while the attachements may be purged after 2 years.
- Using the COSE envelope, the common elements would be represented as protected headers, while the body is a specific content type.
- A ledger instance will always capture the headers, while the ledger may choose to persist the cose body on, or external to the ledger.
Example: all artifacts that contain the log4j, in spdx documents. Another instance may choose to use cyclondx, or a startup may choose to innovate a new contentType.
### Use Cases
Yogesh, Kay and Orie were working on the use case, defining the current situation, where SCITT would then provide a standard means to interop supply chain information across many publishers and consumers across an ecosystem.
#### Producers & Consumers
We also discussed consumers often become producers of aggregated source content.
A software vendor/project consumes many packages. They take an aggregate of the content they consumed and produce a new artifact.
There are leaf nodes, where a company (ACME Rockets) collects the software they will distribute to their end users, or even deployed on servers. The end users/servers don't need the SBOMs and statements, as the decisions is made before deployment.
Monitorying by security scanners may track vulnerabilities, reporting it back to the company. The company would then check it's vendors to see if the latest versions address the specific vulnerability. They don't just pull the latest version (run windows update to hope the problem is solved), rather a check is made to assure the update solves problem X. As pulling the latest may intorduce new problems. Updates should be applied with knowledge.