3 ms·
> There's no reason why some committee couldn't sit down and standardize a format for ancillary data such as the trust date cutoffs mentioned here They already
by ak217 4y ago
> There's no reason why some committee couldn't sit down and standardize a format for ancillary data such as the trust date cutoffs mentioned here
They already have (https://www.rfc-editor.org/rfc/rfc5280.html https://www.rfc-editor.org/rfc/rfc5280.html, https://www.rfc-editor.org/rfc/rfc6960.html https://www.rfc-editor.org/rfc/rfc6960.html) but CRL/OCSP functionality not implemented in most libraries because it's hard and thankless work.
- Ajedi32 4y agoAFAIK those are standards for allowing CAs to revoke certificates. Trust conditions for root stores are a completely different thing. Or at least, I'm certainly not aware of any mechanism in the CRL standard to "partially revoke" a CA certificate based on complex conditions like "What's the notBefore date on the leaf certificate we're currently validating?".
- ak217 4y agoAh I see, you're right I guess they didn't contemplate the scenario of "we want to distrust this CA - against its wishes - but we still trust it enough to make it an orderly transition instead of an emergency". I guess it was previously assumed that CA trust would be binary and that CAs would be cooperative - seems like a pretty common evolution that internet standards go through. The problem is, code that handles these things is safety critical and requires real and sustained investment to be reliable. Given this overhead (and the gaps in CRL/OCSP support that I mentioned), it's unclear if this use case will be common enough to commit to supporting.