Thanks, that’s good to hear. I think that there’s value in the thought experiment of “if Globaltrust for some weird reason asked to be added to the root store now, with a notBefore limit a little ways in the future and only the current trivial. set of certs in the wild, would we allow that? does it make Firefox and the web better for that root to be trusted that way?”
For me the answer is “no, making those handful of certs work is not worth the exposure”. If we don’t remove the root, then I think we should set the notBefore limit to match the last cert that has already been issued. I don’t think we want to honour any certs that GlobalSign issues over the next few weeks… Mike On Wed, Jun 12, 2024 at 10:55 AM 'Ben Wilson' via [email protected] <[email protected]> wrote: > 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 > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/5b7a138e-ce79-4b12-a620-c95584e6fa46n%40mozilla.org?utm_medium=email&utm_source=footer> > . > -- 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/CADQzZqtk4s7KfaS%2BimUh_RKjfTj_aoc6gPzjHdyUJkK0i1gKQw%40mail.gmail.com.
