Also, I'd like to encourage other CAs to comply with Issue 98 pro-actively, even if it is not required. We're already in compliance.
-Tim > -----Original Message----- > From: dev-security-policy <[email protected]> On > Behalf Of Tim Hollebeek via dev-security-policy > Sent: Thursday, August 9, 2018 10:26 AM > To: [email protected] > Cc: Alex Cohn <[email protected]>; mozilla-dev-security- > [email protected]; [email protected]; [email protected]; > [email protected] > Subject: RE: localhost.megasyncloopback.mega.nz private key in client > > Yup, it was Mozilla policy that I was thinking of. Thanks. > > > > I’m sad it didn’t make it into official Mozilla policy, as I thought it was a > pretty > reasonable and non-controversial requirement. I’d support putting it in the > BRs. > > > > -Tim > > > > From: Ryan Sleevi <[email protected]> > Sent: Thursday, August 9, 2018 7:15 AM > To: Tim Hollebeek <[email protected]> > Cc: Alex Cohn <[email protected]>; [email protected]; mozilla-dev- > [email protected]; [email protected]; > [email protected] > Subject: Re: localhost.megasyncloopback.mega.nz private key in client > > > > Unfortunately, that's not correct. The CA/Browser Forum has passed no such > resolution, as can be seen at https://cabforum.org/ballots/ . > > > > I believe you're confusing this with the discussion from > https://github.com/mozilla/pkipolicy/issues/98, which highlighted that the > BRs 4.9.3 requires clear instructions for reporting key compromise. That > language has existed since the BRs 1.3.0 (the conversion to 3647 format). > > > > Alternatively, you may be confusing this discussion with > https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communi > cation , which required CAs to provide a tested email address for a Problem > Reporting Mechanism. However, as captured in Issue 98, this did not result in > a normative change to the CP/CPS. > > > > On Wed, Aug 8, 2018 at 10:22 PM, Tim Hollebeek via dev-security-policy > <[email protected] <mailto:dev-security- > [email protected]> > wrote: > > IIRC we recently passed a CABF ballot that the CPS must contain instructions > for submitting problem reports in a specific section of its CPS, in an > attempt to > solve problems like this. This winter or early spring, if my memory is > correct. > > -Tim > > > > -----Original Message----- > > From: dev-security-policy > > <[email protected] > > <mailto:[email protected]> > On Behalf Of > > Alex Cohn via dev-security-policy > > Sent: Wednesday, August 8, 2018 4:01 PM > > To: [email protected] <mailto:[email protected]> > > Cc: [email protected] > > <mailto:[email protected]> ; > > [email protected] <mailto:[email protected]> ; > > [email protected] <mailto:[email protected]> > > Subject: Re: localhost.megasyncloopback.mega.nz > > <http://localhost.megasyncloopback.mega.nz> private key in client > > > > On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck <[email protected] > <mailto:[email protected]> > wrote: > > > > > > > > As of today this is still unrevoked: > > > https://crt.sh/?id=630835231 <https://crt.sh/?id=630835231&opt=ocsp> > > > &opt=ocsp > > > > > > Given Comodo's abuse contact was CCed in this mail I assume they > > > knew about this since Sunday. Thus we're way past the 24 hour in > > > which they should revoke it. > > > > > > -- > > > Hanno Böck > > > https://hboeck.de/ > > > > > > As Hanno has no doubt learned, the [email protected] > > <mailto:[email protected]> address bounces. > > I got that address off of Comodo CA's website at > > https://www.comodoca.com/en-us/support/report-abuse/. > > > > I later found the address "[email protected] > > <mailto:[email protected]> " in Comodo's latest CPS, and forwarded > > my last message to it on 2018-08-05 at 20:32 CDT (UTC-5). I received > > an automated confirmation immediately afterward, so I assume Comodo > has now known about this issue for ~70 hours now. > > > > crt.sh lists [email protected] <mailto:[email protected]> > as > > the "problem reporting" address for the cert in question. I have not tried > > this > address. > > > > Comodo publishes at least three different problem reporting email > > addresses, and at least one of them is nonfunctional. I think similar > > issues have come up before - there's often not a clear way to identify > > how to contact a CA. Should we revisit the topic? > > > > Alex > > _______________________________________________ > > dev-security-policy mailing list > > [email protected] > > <mailto:[email protected]> > > https://lists.mozilla.org/listinfo/dev-security-policy > > > _______________________________________________ > dev-security-policy mailing list > [email protected] <mailto:dev-security- > [email protected]> > https://lists.mozilla.org/listinfo/dev-security-policy > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
