> I don't know of any issuer key compromises detected with CT. Such compromises are rare. DigiNotar is an obvious example, but can you think of any recent ones?
Is Cirrus mentioned in the blog post? I can't find it.
Right now, the way key compromise might be detected in RPKI is that a human network operator notices a signed object which is obviously suspicious and posts it on a mailing list. This is the same way that CA compromise was detected in the Web PKI before CT.
CT was useful well before Chrome used their weight to make it required for all new certificates because it was no particular burden on a few people (CA or not) who saw a lot of certificates to add them to CT. This gave the people who might not see a lot of certificates but want to find something weird a corpus to dig into.
Same idea applies to RPKI. But yes, setting up Cirrus took very little of my time.
Not sure if this fully addresses your use-case, but I like the idea of serving a static bootloader from IPFS. The bootloader would contain all of a website's assets, and code for getting dynamic content from a backend. The backend could be:
- A central API where the bootloader can do arbitrary validation on the API responses.
I believe the IPFS team has already built a browser extension that runs a js-ipfs node. Running an IPFS node is not ideal for power and bandwidth constrained devices like a mobile phone. This is where I see gateways fitting in, long-term. Not having to trust a gateway unconditionally is necessary to make this viable.