4 ms·

> You might have to ask every CA what their issuance volume was and then compare them all to each other, hoping they weren't presenting figures in creative ways

> You might have to ask every CA what their issuance volume was and then compare them all to each other, hoping they weren't presenting figures in creative ways. Today though, we have a very easy way of determining this This is actually not that important a metric The trend is towards increasingly short lived certificates for both commercial/non-commercial, and also government/military applications. Obviously, this mitigates a large number of things, particularly a compromise. It also means you need automated re-issuances of numerous short lived certificates to accompany this. > Before CT, there could be a significant time lag between a certificate being wrongly issued, and a CA doing something about it. [1] This where CT gets it wrong. Today, there is still a huge time lag between the following steps from A to I: A - Device Compromise/Key Exposure B - Compromise Detected C - Detector identifying Owner of System D - Detector notifying Owner of System E - Owner of System successfully receiving the communication F - Owner notifying CA G - CA performing revocation event H - Revocation event promulgating throughout all the CA/VA infrastructure I - End User / Relying Parties receiving revocation events This, because A & B may be unknown for several years, a large amount of device/hardware/software backdoors in everything that are accessible to nation-state attackers, and the emergence of cloud where private keys are accessible to nation-stake attackers. Nation-states can also compel release of private key data. If you think about things like what happened to Diginotar [2], there is no reason to believe the very same thing couldn't happen again. And CT doesn't really solve problems like that. They'd just be able to help with the eventual cleanup and subsequent removals and potentially, determining blast radius [1] https://certificate.transparency.dev/ https://certificate.transparency.dev/ [2] https://www.securityweek.com/hacker-had-total-control-over-diginotar-servers-report https://www.securityweek.com/hacker-had-total-control-over-d...

zinekeller 5y ago
I think that short-lifetime certificates are still the best, but I do see a value with CT, namely dealing with a newly-acquired domain (especially a domain with a history). Without CT, you're in mercy of other holders being honest unless you contact every single CA to revoke any theoretical certificates that they might or might not issue. With CT, you just need to contact specific CAs that there has been a change in ownership and to revoke any previous certificates issued.
toast0 5y ago
CT isn't expected to help with key exposure (although, it does a bit, because you can probably maybe search by subject public key), its purpose is to make it easier/possible to find issued certificates that shouldn't have been issued. It does a pretty decent job of reducing the window between misissued certificate and CAB Forum discussion. That doesn't protect privacy in specific cases, but it helps in aggregate.

zinekeller 5y ago

I think that short-lifetime certificates are still the best, but I do see a value with CT, namely dealing with a newly-acquired domain (especially a domain with a history). Without CT, you're in mercy of other holders being honest unless you contact every single CA to revoke any theoretical certificates that they might or might not issue. With CT, you just need to contact specific CAs that there has been a change in ownership and to revoke any previous certificates issued.

toast0 5y ago

CT isn't expected to help with key exposure (although, it does a bit, because you can probably maybe search by subject public key), its purpose is to make it easier/possible to find issued certificates that shouldn't have been issued. It does a pretty decent job of reducing the window between misissued certificate and CAB Forum discussion. That doesn't protect privacy in specific cases, but it helps in aggregate.