twiss / source-code-transparency Goto Github PK

Rather than creating a new transparency log, we could evaluate whether sigstore would be sufficient for our purposes.

Since I didn't see it on the TPAC list of related work: https://datatracker.ietf.org/group/scitt/about/
This is quite a bit more generic but might be a good way to solve the problem for source code/web content.
The trust model may be more complicated for the web but a fairly similar use case would be https://www.ietf.org/archive/id/draft-ietf-scitt-software-use-cases-01.html#name-firmware-delivery-to-large-

The explainer says:

To signal to the browser that a given web app is using Source Code Transparency, we could introduce a X.509 certificate extension, which would automatically be included in the Certificate Transparency logs

I don't think the security model quite holds together if the web PKI certificate is the signaling mechanism for when an origin is using Source Code Transparency. CT logs are designed for domain owners to monitor for malicious certificates for their own domains; the domain owner has full information to evaluate whether a certificate that appears in the logs is malicious or not. But in the Source Code Transparency case, it's external observers who would be monitoring the logs, and external observers don't necessarily have the information needed to distinguish an attack from an innocuous scenario (e.g., domain name transfers to new owner, or domain owner decides to stop using Source Code Transparency for some reason). Maybe in some limited scenarios it would be possible to pinpoint suspicious behavior (e.g., presumably a non-Source-Code-Transparency certificate appearing for signal.org would always be deemed suspicious), but I don't think it's a satisfying security story in general.

I think a more satisfying security story would involve some kind of browser-side enforcement, like origin separation when Source Code Transparency is in use vs when it's not -- though this is a complicated technical proposition. Another option could be some kind of browser UI that distinguishes the use of Source Code Transparency, but that's kind of icky. Or there could be some kind of pinning/HSTS-like solution where an app can ask the browser to refuse to load it subsequently if Source Code Transparency is not in use... I don't love any of these ideas, so I don't know what the right answer is, but I did want to note that the security story is unsatisfying IMO if we're relying on external observers to distinguish innocuous from malicious signals in CT logs.

I'll also note that extending web PKI certificates for this use case could be undesirable in other ways. It could complicate the path to deployment, as multiple CAs would need to get on board with signing this new extension, and there might be a tension between automating TLS certificate management and using Source Code Transparency, until automated certificate management software adapts to support the extension (if it ever does).

The working title "Source Code Transparency" may be confusing since what we want to hash & publish is not necessarily the original source code but rather the "compiled" web bundle that's distributed. If we go the route of hashing web bundles only, perhaps something like "Web App Transparency" or "Web Bundle Transparency" might be better?