Software signatures and upcoming standards about remote attestation

[deeglaze]

Hi y'all, I work on Google Cloud's confidential computing and am particularly focused on security the software supply chain. I'm interested in protecting customers from Google as computer operators, and not the other way around, i.e., end user device DRM.

I'm here to ask about collaboration on standards for the deps.dev API to participate in a federated future.

The IETF has a few work streams that all synergize to make the entirety of a VM's firmware, OS, middleware, and application stack remotely attestable (RATS for remote attestation, and WIMSE for workload identity) in a manner such that every digest can be tied back to the source bits and builder container (SCITT).

The sigstore.dev project allows software vendors to tie their build provenance to a trusted append-only log for authentication and non-repudiation. This log combined with the carrier format of build provenance in https://slsa.dev is a potential implementation of SCITT. Microsoft's CACM article "Why should I trust your code?" describes a Code Transparency Service that is also a potential implementation.

Whereas SLSA uses in-toto attestations that can be rather bulky, the IETF RATS working group is proposing concise representations in the form of CWT for attestation tokens representing checked claims and CoRIM for software digests and endorsed claims of their properties.

All of the RATS draft specifications are getting co-designed with reference implementations in the github.com/veraison project. The primary software outside of parsers is the Verifier. There is a provisioning service that allows reference value providers to inform the Verifier of values, but it's not designed to be database that cooperates with other verifier implementations

I see deps.dev as a potential implementation of a reference value service. I also don't think that deps.dev should be a monolith. Instead we can have multiple providers operating within the fediverse. The working group has only focused on the carrier format for endorsements and reference values (CoRIM), but to be truly successful I think that all the elements of productionizing the components conceptualized in RFC9334 should be available as open source projects.

I invite y'all to come on over to https://datatracker.ietf.org/wg/scitt and https://datatracker.ietf.org/wg/rats for discussions so we can converge on a happy open ecosystem where we can all make software more provably secure in real systems.