Non-browser clients shouldn't be expected to crib browser trust decisions. Also, the (presumably?) default behavior for a non-browser client consuming a browser root store, but is unaware of the constraint behavior, is to not enforce the constraint. So they would effectively continue to trust the CA until it is fully removed, which is probably the correct decision anyway.
To me that's an odd position to take, ultimately if the user is using Mozilla's root CA list then they're trusting Mozilla to determine which certs should be valid. If non-browser programs using the list are trusting certs that Mozilla says shouldn't be trusted then that's not a good result.
Now of course the issue is that the information can't be encoded into the bundle, but I'm saying that's a bug and not a feature.
Mozilla’s list is built to reflect the needs of Firefox users, which are not the same as the needs of most non-browser programs. The availability/compatibility vs security tradeoff is not the same.
> the information can't be encoded into the bundle
Can it not? It seems like this SCTNotAfter constraint is effectively an API change of the root CA list that downstream users have to in some way incorporate if they want their behavior to remain consistent with upstream browsers.
That doesn't necessarily mean full CT support – they might just as well choose to completely distrust anything tagged SCTNotAfter, or to ignore it.
That said, it might be better to intentionally break backwards compatibility as a forcing function to force downstream clients to make that decision intentionally, as failing open doesn't seem safe here. But I'm not sure if the Mozilla root program list ever intended to be consumed by non-browser clients in the first place.
> That doesn't necessarily mean full CT support – they might just as well choose to completely distrust anything tagged SCTNotAfter, or to ignore it.
That's what the blog post I linked in the top comment suggests is the "more disruptive than intended" approach. I don't think it's a good idea. Removing the root at `SCTNotAfter + max cert lifetime` is the appropriate thing.
There's an extra issue of not-often-updated systems too, since now you need to coordinate a system update at the right moment to remove the root.
> Removing the root at `SCTNotAfter + max cert lifetime` is the appropriate thing.
Note that Mozilla supports not SCTNotAfter but DistrustAfter, which relies on the certificate's Not Before date. Since this provides no defense against backdating, it would presumably not be used with a seriously dangerous CA (e.g. DigiNotar). This makes it easy to justify removing roots at `DistrustAfter + max cert lifetime`.
On the other hand, SCTNotAfter provides meaningful security against a dangerous CA. If Mozilla begins using SCTNotAfter, I think non-browser consumers of the Mozilla root store will need to evaluate what to do with SCTNotAfter-tagged roots on a case-by-case basis.
> But I'm not sure if the Mozilla root program list ever intended to be consumed by non-browser clients in the first place.
Yet that is the thing that goes around under the name "ca-certificates" and practically all non-browser TLS on Linux everywhere is rooted in it! Regardless of what the intent was, that is the role of the Mozilla CA bundle now.
