Systems like Certificate Transparency and Key transparency store trees of keys/certificates. How would a user be able to remove a fraudulent/expired key or certificate? Do the trees stay the same and a separate list of revoked keys/certificates is maintained?
Add a comment
|
1 Answer
The certificate log of CT is based on Merkle trees and therefore only permits appending new certificates. This is a very important property, because it prevents attackers from modifying any historical data. It also means once a certificate has been added to the log, it cannot be removed, not even by the CA which issued the certificate or the user who owns the private key corresponding to the certificate's public key.
CT currently doesn't deal with certificate revocation at all, even though there have been proposals to extend CT with revocation information. Right now, we still need to use the classical mechanisms to provide this data: Certificate Revocation Lists or the Online Certificate Status Protocol (OCSP); the latter can be used together with OCSP Stapling to include the certificate status directly in the handshake.
