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 <dev-security-policy-boun...@lists.mozilla.org> On > Behalf Of Tim Hollebeek via dev-security-policy > Sent: Thursday, August 9, 2018 10:26 AM > To: r...@sleevi.com > Cc: Alex Cohn <a...@alexcohn.com>; mozilla-dev-security- > pol...@lists.mozilla.org; ha...@hboeck.de; ssl_ab...@comodoca.com; > summern1...@gmail.com > 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 <r...@sleevi.com> > Sent: Thursday, August 9, 2018 7:15 AM > To: Tim Hollebeek <tim.holleb...@digicert.com> > Cc: Alex Cohn <a...@alexcohn.com>; ha...@hboeck.de; mozilla-dev- > security-pol...@lists.mozilla.org; ssl_ab...@comodoca.com; > summern1...@gmail.com > 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 > <dev-security-policy@lists.mozilla.org <mailto:dev-security- > pol...@lists.mozilla.org> > 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 > > <dev-security-policy-boun...@lists.mozilla.org > > <mailto:dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of > > Alex Cohn via dev-security-policy > > Sent: Wednesday, August 8, 2018 4:01 PM > > To: ha...@hboeck.de <mailto:ha...@hboeck.de> > > Cc: mozilla-dev-security-pol...@lists.mozilla.org > > <mailto:mozilla-dev-security-pol...@lists.mozilla.org> ; > > ssl_ab...@comodoca.com <mailto:ssl_ab...@comodoca.com> ; > > summern1...@gmail.com <mailto:summern1...@gmail.com> > > 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 <ha...@hboeck.de > <mailto:ha...@hboeck.de> > 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 ssl_ab...@comodoca.com > > <mailto:ssl_ab...@comodoca.com> 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 "sslab...@comodo.com > > <mailto:sslab...@comodo.com> " 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 sslab...@comodoca.com <mailto:sslab...@comodoca.com> > 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 > > dev-security-policy@lists.mozilla.org > > <mailto:dev-security-policy@lists.mozilla.org> > > https://lists.mozilla.org/listinfo/dev-security-policy > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org <mailto:dev-security- > pol...@lists.mozilla.org> > https://lists.mozilla.org/listinfo/dev-security-policy > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
