Note that if you don't trust the CA, you shouldn't trust the issue date either. A dishonest CA would backdate any certificates signed.
So having an arbitrary cutoff date in software seems unnecessary. If you still trust the CA to behave honestly for now, then you can simply instruct them not to issue any more certificates.
If you don't trust the CA to act honestly for now, then you need to remove them from the trust store entirely (and maybe use a whitelist of previously issued certificates if you believe they were trustworthy in the past).
> Note that if you don't trust the CA, you shouldn't trust the issue date either. A dishonest CA would backdate any certificates signed.
Dare I say it, but isn't this the exact problem solved by a chain of published certificate hashes?
This is pretty much how certificate transparency lists (CTL) work too. It's like a blockchain without any proof of work or stake, just a merkle tree of hashes that ensures you cannot retroactively insert one with an older date.
> ... (and maybe use a whitelist of previously issued certificates if you believe they were trustworthy in the past).
Which I guess would be only trusting CTL published certificates up until the last point of trust.
You're not describing a blockchain here, but rather a Merkle tree (also called a hash tree). Or, (because the tree-like behavior is actually undesirable here) just an array of hashes.
Just because something has a set of hashes in a roughly linear timeline doesn't make it a blockchain. For example, git isn't a blockchain either.
Clearly you disagree on the definition of the word “blockchain”. Let's consult Wikipedia, a trustworthy source on anything [1].
> A blockchain is a type of distributed ledger technology (DLT) that consists of growing lists of records, called blocks, that are securely linked together using cryptography. [...] Since each block contains information about the previous block, they effectively form a chain, with each additional block linking to the ones before it. Consequently, blockchain transactions are irreversible in that, once they are recorded, the data in any given block cannot be altered retroactively without altering all subsequent blocks.
So far this is exactly what's going on in the Certificate Transparency scheme.
> Blockchains are typically managed by a peer-to-peer (P2P) computer network for use as a public distributed ledger, where nodes collectively adhere to a consensus algorithm protocol to add and validate new transaction blocks.
This part deviates from CT (no validation is going on in real time, browsers usually just have a few hardcoded CT logs and a custom rule on when a certificate is trusted). But note the word “typically”: this doesn't mean CT can't be called a blockchain just because it doesn't use PoW, PoC or any other consensus algorithms conventional in the cryptocurrency world.
Calling Git a blockchain is arguably more of a stretch because the purpose of keeping the old records intact is not what we use Git for. Maybe you can build blockchain on Git though? (edit: OF COURSE YOU CAN https://github.com/CouleeApps/git-power)
So having an arbitrary cutoff date in software seems unnecessary. If you still trust the CA to behave honestly for now, then you can simply instruct them not to issue any more certificates.
If you don't trust the CA to act honestly for now, then you need to remove them from the trust store entirely (and maybe use a whitelist of previously issued certificates if you believe they were trustworthy in the past).