RE: localhost.megasyncloopback.mega.nz private key in client

[Jay Wilson via dev-security-policy]

+Adding Robin Alden and Richard Smith


-Original Message-
From: Hanno Böck  
Sent: Thursday, August 09, 2018 10:51 AM
To: Jay Wilson via dev-security-policy 
Cc: Jay Wilson ; Alex Cohn ; 
ssl_ab...@comodo.com; mozilla-dev-security-pol...@lists.mozilla.org; 
summern1...@gmail.com
Subject: Re: localhost.megasyncloopback.mega.nz private key in client

On Thu, 9 Aug 2018 13:24:48 +
Jay Wilson via dev-security-policy
 wrote:

> The certificate has been revoked.
> The bounce issue has been escalated to resolve.

Really?

$ ocspverify 630835231.crt 
Response verify OK
630835231.crt: good
This Update: Aug  4 15:34:50 2018 GMT
Next Update: Aug 11 15:34:50 2018 GMT


crt.sh also says "Good" on OCSP:
https://crt.sh/?id=630835231=ocsp

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: localhost.megasyncloopback.mega.nz private key in client

[Jay Wilson via dev-security-policy]

+Adding Robin Alden and Richard Smith

From: Ryan Sleevi 
Sent: Thursday, August 09, 2018 8:15 AM
To: Tim Hollebeek 
Cc: Alex Cohn ; ha...@hboeck.de; 
mozilla-dev-security-pol...@lists.mozilla.org; #SSL_ABUSE 
; 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 
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 
> 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
> Cc: 
> mozilla-dev-security-pol...@lists.mozilla.org;
>  ssl_ab...@comodoca.com;
> summern1...@gmail.com
> Subject: Re: 
> localhost.megasyncloopback.mega.nz 
> private key in client
>
> On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck 
> mailto:ha...@hboeck.de>> wrote:
>
> >
> > As of today this is still unrevoked:
> > https://crt.sh/?id=630835231=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 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" 
> 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 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
> https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
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
https://lists.mozilla.org/listinfo/dev-security-policy

RE: localhost.megasyncloopback.mega.nz private key in client

[Jay Wilson via dev-security-policy]

The certificate has been revoked.
The bounce issue has been escalated to resolve.
Regards,

From: Alex Cohn 
Sent: Wednesday, August 08, 2018 5:01 PM
To: ha...@hboeck.de
Cc: summern1...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org; 
#SSL_ABUSE 
Subject: Re: localhost.megasyncloopback.mega.nz private key in client


On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck 
mailto:ha...@hboeck.de>> wrote:

As of today this is still unrevoked:
https://crt.sh/?id=630835231=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 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" 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 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
https://lists.mozilla.org/listinfo/dev-security-policy