Dear Andrew and all,
We understand your concerns. We are evaluating and considering your suggestions. Thanks, Ben Wilson Mozilla Root Program Manager On Tuesday, June 11, 2024 at 4:58:02 PM UTC-6 [email protected] wrote: > 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/5b7a138e-ce79-4b12-a620-c95584e6fa46n%40mozilla.org.
