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_Communication , 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-policy@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-policy@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
