I have to echo the sentiments, and question what setting a notBefore date weeks into the future signals to a non-compliant CA. If we're already in agreement that trust is lost, what does this grace period provide if not more room for either unintionally malicious, or actively malicious actions even by a third party? Any actions that have caused a CA to get into this trust state are doubtless continuing in the leadup to the final notBefore day.
Isn't this in effect a tacit agreement for a non-compliant CA to do what they wish for the next few weeks, because ultimately what is going to happen if they don't? What would be a root program's response is on the issuance of a distrust statement a CA then quietly sells non-SCT certificates for, say, interception purposes? It's a narrower window of opportunity but I can see a CA who is looking to make one last grab for cash on the way out abusing this system as it stands. I'm of the opinion that we need to build these enforcement mechanisms defensively and presume a malicious party if only for the security implications. I can see an argument for a few days for the CA to recognize they are no longer trusted and to remove all documentation stating that their future issuances would work in specific root chains. I just don't see the security or integrity rationale in such a wide window, although I recognize that it has previous precedent I'd echo my statements to those as well. - Wayne On Tuesday, June 11, 2024 at 10:55:29 PM UTC+1 Mike Shaver wrote: > I have to agree with Andrew. Continuing to trust this root and the > integrity of "notBefore" on the certs it issues seems like it adds risk to > Firefox and Thunderbird users without basically any value to the world. If > those certificates have their key material leak, do we have any reason to > believe that ECM will actually spring to life and help the subscribers? I > cannot think of such a reason. > > IMO we should excise it cleanly, and let Mozilla's users deal with the > fact that they can't access those handful of sites--if indeed they ever > ever notice. > > Mike > > > On Tue, 11 Jun 2024 at 15:55, Andrew Ayer <[email protected]> wrote: > >> On Tue, 11 Jun 2024 13:11:16 -0400 >> Andrew Ayer <[email protected]> wrote: >> >> > If we exclude ECM's own domains, this drops down to just 36 distinct >> > DNS names. >> >> Further analysis: of the 36 DNS names, >> >> 18 are serving a non-ECM certificate on port 443 >> 9 are serving an ECM certificate on port 443 >> 6 did not respond on port 443 >> 3 are wildcard DNS names >> >> Regards, >> Andrew >> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected]" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20240611155511.4871da6bf1be264046b9d62d%40andrewayer.name >> . >> > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/89daaf3d-265d-482e-bd30-e0414f227fe3n%40mozilla.org.
