> The Static Certificate Transparency API defines a read-path HTTP static asset hierarchy (for monitoring) to be implemented alongside the write-path RFC 6962 endpoints (for submission).
> Aside from the different read endpoints, a log that implements the Static API is a regular CT log that can work alongside RFC 6962 logs and that fulfills the same purpose. In particular, it requires no modification to submitters and TLS clients.
Huge huge speed up, making a CT Log that can be read relatively easily from some static files. Versus it sounds like before every query requiring a rather computationally intensive series of lookups.
Filippo has their own great thread on this work too, highly recommend: https://bsky.app/profile/filippo.abyssdomain.expert/post/3lo...
It cites an interesting new spec c2sp, https://c2sp.org/static-ct-api :
> The Static Certificate Transparency API defines a read-path HTTP static asset hierarchy (for monitoring) to be implemented alongside the write-path RFC 6962 endpoints (for submission).
> Aside from the different read endpoints, a log that implements the Static API is a regular CT log that can work alongside RFC 6962 logs and that fulfills the same purpose. In particular, it requires no modification to submitters and TLS clients.
Huge huge speed up, making a CT Log that can be read relatively easily from some static files. Versus it sounds like before every query requiring a rather computationally intensive series of lookups.
Great stuff! I’m wondering whether a similar architecture might work for other systems. Could a bluesky relay work like that?