There are 2 differences. First, in the event HSTS was activated on the site there will be no chance to override. Second, a user in that region may want to or need to activate that root because he or she relies on the impacted websites. Another concern is that the case by case override might still result in marginally usable sites because the embedded requests (css, js, images, iframes) could fail ("unknown issuer") without any chance to add exceptions for them. Being able to manually re-enable trust would serve as a useful remedy for them while still protecting the rest of the Internet populace. In looking at that list of unexpired certs that chain to this root it looks like there could be a lot of people who will be surprised or upset when they can't use Firefox anymore to get to those sites. It seems pretty clear that this CA should not be trusted but I'd hate for that to turn into a situation where people in Turkey stop using Mozilla products. As a sort of tanget, but not really, I was also thinking about the impacts to other products/projects that rely on this trust store. For this specific root it's hard for me to see a case where a problem might arise ("my embedded product stopped working!") it's probably worth keeping in mind anyway. Thanks.
On 3/19/15 11:51 AM, Peter Kurrasch wrote: > Would it be an option to remove the trust bits on the root first and then later on remove it from the store entirely? > I don't see how removing the trust bits instead of removing the root helps. In both cases the user will see the over-rideable "This Connection is Untrusted" error with (Error code: sec_error_unknown_issuer) Kathleen _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy | ||
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
