6th, November 2024
The chairs have covered the notewell and being excellent to each other
with broad acknowledgement from the participants
Henk: Providing and overview of Supply Chain Integrity, Transparency,
and Trust.
Interoperable building blocks that enable inegrity, transparency, and
accounatability focused on software supply chains
Architecture ready for WGLC, next priority is on SCRAPI (the API side of
interacting with SCITT instances)
A number of supporting docs, especially in COSE for receipts, proofs,
envelopes, etc. A request to attend COSE on friday for more details.
Particularly notes on detached payloads
Typically Issuers are making statements about (software) artifacts, and
getting a signed receipt back from the SCITT instance. What is said, how
it is said, etc are opaque to the service.
A notary is a good analogy, since a notary observes and witnessess, but
does not pass judgetment. A key item is that statements cannot be taken
back, which provides transparency and auditablity.
CDDL is used for description of payloads, headers, claims, and other key
items, especially in CWT (which is used for signing items). Items that
need to be signed go in the protected header.
A key item of note, is that x5t provides a way to embed the hash of the
public key associated with signing.
Small COSE receipts is the idea, so areas that provide smaller payloads
are important.
Items are optional in the CDLL, so there is path to future upgrades
around identity linked to key pairs. X509/pkx is the starting place.
When using x509, x5t is a MUST. When another identity solution is used,
it may hav different requirments.
When we think about what is in "streams" of information coming out of
the transparency service, this covers items like certifications, test
case data, versions, who is providing statement, etc.
Emphasis that SCITT does not define content types - but it leverages
them to provide hints to the semantics of the payloads for users of the
system. SCITT provides WHO, WHAT, WHEN.
Orie: Covering history and uptake of transparency as a broad concept and
best practice requirement for software supply chain. This has increased
significantly since 2022 which SCITT was started.
SCITT is diferentiated by the fact that the type of content is not
limited by the spec and architecture.
Recent dev summits in the broader community, especially in Golang,
focused on transparency, especially transparency.dev
OMB Memos, NTIA, NIST SPs, and EOs setting out requirements that mandate
or strongly recommend transparency for software supply chains.
SCITT is getting direct recognition and callouts in key implementation
guides and other guidance, including from regulatory agencies like the
FCC.
Related items in keytrans - proof types and log structures especially.
SCITT was designed to permit rapid adoption of new log formats like
this.
Transparency is being increasingly built into various services to
provide transparency. Examples include cloudflare + whatsapp, MS,
others.
There is a call to action for the group to applaud this adoption of
transparency, and to promote use of SCITT as a fundamental building
block for interoperable transparency.
Orie: Reuqest for questions or other notes of transparency in the wild.
Mike Prorock: Using SCITT as a means to secure critical infrastructure
by linking software and hardware supply chains. Leveraging SCITT for
audit trails and physical security, for US Customs scenarios, and in
particular for legal system of record to respond to regulatory actions
from various governmental agencies. All possible becuase we now have a
standards approach to auditing.
Li Lun: Question: beleive the transparency service is very good. Very
similar to distributed ledgers, like hyperledger. Have we considered
blockchain community.
Orie: take a look at the secure transport protocols, looking at the same
physical supply chain scenarios. Small overlap between these services,
including proofs and proofs of consistency. You also see these
merkletree definitions show up across the ledger technologies. This is
also why we've created a registry for different types of ledger
profiles, for different storage formats. Reading the drafts, are there
other formats that might be interesting.
AJ: Question: what do these transparency in the news mean for work in
the WG?
Orie: This lets us highlight that transparency is both inside and
outside the IETF and is a desired shared goal, and where possible we
should be aligning deployments around deployed code and where
appropriate guide other initiatives to leverage the interoperable
components we are developing here.
Steve Lasker: Primary focus has been on polish on the architecture - 15
issues leading to 21 PRs to clean things up and get the draft ready for
WGLC. A lot of trimming involved as well as language clean ups and
refinements to remove early artifacts. Cleanup and correction of CDDL
and EDN across the board.
Hannes: Comments on the responsiveness of the WG and the authors to take
feedback into consideration and respond appropriately.
Steve: Finishing up other key items in other groups (notably COSE)
There is now a stabalized archtecture diagram and flow for all key items
of the architecture. Roles and details and terminology have also all
been stabalized.
Signing of statement(s) takes place before hitting the transparency
service. What is returned is a receipt. The other details around
storage, policies, etc, are left to implementations. Linking a signed
statement with a receipt is what provides transparency.
Jon Geater: taking off his chair hat.
Last time, proved this works, from statement creation to registration on
a blockchain based ledger. You might imagine we're done, but not quite.
We're now up to 23 issues, most of which have PRs. Most of whats left
appears to be small. Worth noting have any bearing on the architecture.
The stuff in PRs broadly falls into two camps.
The interesting one to raise, using 9457 for a details object, or a
construct another, or use 9220. Current plan is to use 9220. Focusing on
long running operations. Need to respond in miliseconds, yet most
ledgers take longer.
Michael Richardson has provided great feedfack we're considering. May
remove the resolve statement. Feels more philosophoically correct.
For discussion: Identifiers, what's the meanings and semantics. They're
basically locators. If I want a receipt, I get a locator, that's chosen
by the trnsparency service, not the client. We have been discussing
using the client to define, however, we've landed on using the TS to
create the ID.
Issue Signed Statement: allows constrained devices that may not have an
issuer signing key. It you may want to hold this super important
resources more closely. The TS can do the signing on the clients behalf.
Have done an implementation with DigiCert to prove it works. Definitley
useful, or somethingthe TS does is an open question.
Mike Prorock: I'd be highly concerned if we didn't define an API, to
swap between different signing environments, for confidential compute.
If this isn't defined, you'd have to write crazy custom code. It's not
to say every TS must implement it, but if you do, having it defined
consistently is much better.
Consistency Proofs: proving the TS isn't lying to you. It's very easy to
make an attestation this is good, and another that says it's bad. This
is very important, but probably doesn't belong in SCRAPI, rather in the
auditor role.
Supppor for multiple notaries is important for multiple regions. Can
likely get this done without changes.
Request nonce endpoint. It's mentioned in other RFCs, but may not be
needed in SCRAPI.
Jon: How easy is it (SCRAPI) to use?! Well, oops there might be some
"mind bending" aspects, like returning JSON sometimes, CBOR other times,
really need to line things up to "CBOR all the things".
Another project was also verifying SCITT for software supply chain
artifacts.
Another implementation of SCRAPI and also 9290
Very hard to get started, but ChatGPT nailed it, gave the spec and
running code with tests. Appeared to be allergic to negative numbers,
but otherwise was pretty impressive. Also did a great job of converting
JSON to CBOR.
Also seen was application by Nobuo-san of SCRAPI to yang statements.
Key takeawawys were that SCRAPI is on the right track, and now needs
more implementations to test.
Thomas Howe: Involved with the vCon WG. Using vCons as a way to test
SCITT & SCRAPI. What would be the right intersection between vCons and
the vCon lifecycle. There's an opportunity to improve upon the set and
forget.
The reason SCITT and vCons work well, is it helps with privacy and
government requirements. vCons can be added and changed over time, being
put on the leger for the auditor, and develoeprs, for varisous changes,
such as creation, change of consent for purpose. No longer is is simply
consent, rather consent for a specific purpose.
Diagram: two people are talking, and that gets put on the SCITT ledger.
As the vCon is processed, or revoked, it's put on the Ledger. Now
consumers can now how there data is used. They want the ability for
SCRAPI to provide a list of events, based on the ID, which is the vCon
ID, or the issuer that made the vCon in the first place. As we begin to
vet out SCRAPI, it's working pretty good.
In the protected header we also have the vCon operation, and the issuer.
SCRAPI works pretty well for what they need.
Chris: Poll: Do you beleive the architecture document draft is ready for
WGLC: yes:15, no:0, no opinion:14
Jon: focusing on the github workflow, with weekly progress sent to the
scitt alias.
Any comments on interims before IETF 122?
No open questions.
Jon/Chris
That's the sign of a stable working group.
Thanks you