while tethically out of scope for this thread, is there reason for browsers to include offendgind certificates into CRLlite/CRLset without waiting for CA to agree about that?
2024년 6월 25일 화요일 오전 7시 7분 30초 UTC+9에 Watson Ladd님이 작성: > So I've finally gotten around to reading it. I was a little confused > by the lack of real introduction but it is much more detailed. > > However, you're still missing one of the 2020 bugs, namely > https://bugzilla.mozilla.org/show_bug.cgi?id=1658792. And when I look > at that against https://bugzilla.mozilla.org/show_bug.cgi?id=1897630 I > see the answer to what confused me about the organization of the bugs: > Entrust is overly reliant on humans doing things. It's been organized > in a way where a single human can err and create a missiuance by not > seeing an email, or filling out a form in a natural way. It's a > systemic weakness that this second report only sort of covered, and > never really dug into. The answer to the geography issues wasn't > automated checking: it was changing the UI, enabling a different kind > of error to still happen. > > Some CAs would have used additional automation as a solution: > validating geographical information against available lists (as > promised in that bug). Those CAs would likely also have implemented > monitoring themselves of their OCSP responders, mapped from the CAB > forum requirements. Culturally they would have been more oriented to > creating tickets on emails and using the ticket tracking system to > help ensure that response times were being met and reported on. > > Sincerely, > Watson Ladd > > > > On Fri, Jun 21, 2024 at 11:59 AM 'Bruce Morton' via > [email protected] <[email protected]> > wrote: > > > > Attached is a letter from Bhagwat Swaroop, President of Entrust Digital > Security Solutions, along with an updated response to address questions > from the community. > > > > Thanks, Bruce. > > > > On Tuesday, June 18, 2024 at 1:35:48 PM UTC-4 Amir Omidi (aaomidi) wrote: > >> > >> I am not going to say with certainty that Entrust is definitely putting > Chrome over Mozilla. However, I hope they know that most Linux systems out > there use the Mozilla root store directly. > >> On Tuesday, June 18, 2024 at 1:12:19 PM UTC-4 Mike Shaver wrote: > >>> > >>> On Tue, Jun 18, 2024 at 12:49 PM Walt <[email protected]> wrote: > >>>> > >>>> I'd just like to point out that we now have a situation where Entrust > is in the position of seemingly valuing the opinion of other Root Programs > over Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c42 > >>>> > >>>> In Comment #37, it was hinted at (and made slightly more explicit in > #39) that the opinion of the Mozilla RP is that the attempt to > re-characterize these certs was not going to be looked kindly upon, and > only once a Google RP member explicitly said that it was the Google RP > opinion that the certs remained mis-issued was any movement made on > re-confirming the mis-issuance and taking action to revoke them. > >>>> > >>>> Also, if we're in a position where Entrust is finally able to commit > to revoking certs within a 5 day period (setting aside that these certs > technically need a delayed revocation bug as the mis-issuance was known as > far back as 2024-04-10), why are other incidents not able to be resolved in > this amount of time? Is it because Google showed up? > >>> > >>> > >>> We’ve seen this behaviour in other incidents as well, I believe > including the cpsURI one that has turned into a magnet for evidence of poor > operation and lack of transparency and responsiveness. I remarked on it in > my initial snarky reply to the Entrust Report, in fact. > >>> > >>> From a realpolitik perspective their behaviour could indeed be > rational, especially when the only tool root programs have is distrust. > Firefox would suffer substantial market disadvantage if it stopped trusting > Entrust certificates when other browsers didn’t. I think people generally > underestimate how much Mozilla would be willing to take near-term pain to > protect users, but it’s also possible that I am overestimating it. > >>> > >>> Related to that, I think Chrome’s root program representatives have > generally been more willing to take a concrete position quickly, so Mozilla > might be waiting for more explanation when Chrome decides that there’s no > explanation that could suffice, or similar. The root programs tend to be in > agreement more often than not (virtually always with Chrome and Mozilla, I > would say, excepting some slightly different root store populations), so it > may be somewhat irrelevant whose opinion spurs motion. > >>> > >>> Realpolitik analysis aside, I do agree that Entrust has created the > impression that they care much more about Chrome’s opinion than Mozilla’s, > which IMO might not be the best posture to take given that Mozilla and its > community are the locus for the processing and evaluation of the incidents > in question. > >>> > >>> Mike > >>> > >>> > >>> > > -- > > 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/f3cebe9b-fa25-4b11-ba3d-b7f3f6e0f719n%40mozilla.org > . > > > > -- > Astra mortemque praestare gradatim > -- 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/787ec376-be8e-47dc-9294-7d47d1b23667n%40mozilla.org.
