News for hackers. Stuff that matters.
Re:Linux Certificate Authority root stores have a too simple... by ak217 on Tuesday December 06, 2022 @09:08AM (#33879968)
> 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/rfc6960.html) but CRL/OCSP functionality not implemented in most libraries because it's hard and thankless work.

Re:Linux Certificate Authority root stores have a too simple... by Ajedi32 on Tuesday December 06, 2022 @09:32AM (#33880478)
AFAIK 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?".

Re:Linux Certificate Authority root stores have a too simple... by ak217 on Tuesday December 06, 2022 @11:54AM (#33883165)
Ah 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.