5 ms·

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 va

by DSMan195276 2y ago

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.

dadrian 2y ago
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.
lxgr 2y ago
> 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.
- mcpherrinm 2y ago
  > 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.
  - agwa 2y ago
    > 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.
- yencabulator 2y ago
  > 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.

dadrian 2y ago

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.

lxgr 2y ago

> 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.

mcpherrinm 2y ago
> 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.
- agwa 2y ago
  > 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.
yencabulator 2y ago
> 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.