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.
1. 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? Mostly CA incompetence is more subtle that "Oops we left the root keys on a train" and I'd hope the same is true for RIRs.
2. Technically CT is still not required. You can choose to obtain certificates which aren't logged from a CA that will issue them without logging. Neither Google nor Mozilla require you to log all certificates as a condition of their root programmes and both recently confirmed they do not intend to make that a requirement. Chrome will mark your cert as untrustworthy if it hasn't got an SCT and so it would always make sense to log certificates for a site Chrome users will access on the public Web, but not every TLS certificate is for a web site accessed with Chrome.
[ Also, Google actually makes use of the fact that certs can exist without being logged for some systems. Suppose they're about to launch amazing.example.com, but even the Amazing name would give away what it is. They can order the cert for amazing.example.com with no logging and stockpile it, and when the brass signs off on actually announcing Amazing they log this cert, almost instantly getting back SCTs, and configure a suitably modern web server to send the SCTs separately alongside the certificate. Where ordering a certificate internally might take hours or days, these final steps can be done in a few minutes and need no special permission. Any subscriber whose CA is willing to issue unlogged certificates can do this, but just make sure you have all the steps correct or you'll look really dumb, even Google got this wrong at least once since they began doing it ]
> 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?
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.