Re: How to submit WebTrust audits in CCADB

[jomo via dev-security-policy]

I contacted CPA Canada in early 2017 about XSS and some other issues on
cert.webtrust.org.

They did not fix the issues but stated:

> CPA Canada is currently working on upgrading the WebTrust site to
> enhance the security.
As of April 2018 the issues were still unfixed. I wonder if the limited
access is part of those security "enhancements"?

PS: This change also breaks "legitimate" WebTrust Seal links when either
the website or the web browser is configured to not send the "Referer"
header.

jomo

On 10.8.18 01:19, Kathleen Wilson via dev-security-policy wrote:
> All,
>
> In their effort to better protect WebTrust seals, CPA Canada has made
> it so we can no longer access WebTrust pdf files directly from the CCADB.
>
> I received the following response when inquiring about this.
> “”
> Thank you for contacting Chartered Professional Accountants of Canada.
> You can no longer link directly to PDF documents. You will need to go
> to the registered website where the seal is provided and click on the
> seal to obtain the document (e.g. audit report).
> Also, we are now enforcing the domain requirement when a seal is
> opened.  Domain enforcement is essential to the program to prevent
> fraudulent use. It ensures that the WebTrust seals will only function
> on the certificate authority’s websites.
> If a seal is opened from a non-registered domain or other source (e.g.
> email, internal lists, etc.) the seal will not load and will display a
> notice indicating that the domain is not valid.
> “”
>
> Therefore, for the foreseeable future, please do the following when
> creating an Audit Case in the CCADB for WebTrust audits.
>
> 1) Make the PDFs of the audit statements available directly on your
> CA's website.
> OR
> Upload your audit statement PDF files to Bugzilla, as described here:
> https://ccadb.org/cas/fields#uploading-documents
>
> 2) For the audit statement link in your CCADB Audit Case either
> provide the URL to the PDF on your CA's website, or use the link to
> the document in Bugzilla.
>
> 3) Add a Audit Case Comment to indicate the URL where the WebTrust
> seals may be found on your CA’s website.
>
> 4) When you run the Audit Letter Validation (ALV), you can ignore the
> “Cleaned=Fail” ALV result. I will check the seal on your website
> manually, and add a comment to the Audit Case.
>
>
> Also, the cert.webtrust.org audit links that are currently in the root
> cert records and the intermediate cert records in the CCADB no longer
> work either. Fortunately we started archiving audit statements this
> year. So you can scroll down to the “File Archive…” section of the
> record, and you will be able to find the stored audit pdfs.
>
> Thanks,
> Kathleen
>
>
> ___
> 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: How to submit WebTrust audits in CCADB

[Wayne Thayer via dev-security-policy]

I don't think I'm giving away any big secret by revealing that the seal
website is just doing an http_referer check. If you are blocked when trying
to access an audit report on cert.webtrust.org, just set the referer to the
CA's domain name and refresh. You can do this with any number of Firefox
extensions, such as Referer Control (
https://addons.mozilla.org/en-US/firefox/addon/referercontrol/).

Now if only it were that easy to access prior period reports...

On Thu, Aug 9, 2018 at 4:47 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Thanks for the update, Kathleen.
>
> This is truly unfortunate, and unquestionably does harm to the value and
> brand of the WebTrust Seal, rather than provide value.
>
> On Thu, Aug 9, 2018 at 7:19 PM, Kathleen Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > All,
> >
> > In their effort to better protect WebTrust seals, CPA Canada has made it
> > so we can no longer access WebTrust pdf files directly from the CCADB.
> >
> > I received the following response when inquiring about this.
> > “”
> > Thank you for contacting Chartered Professional Accountants of Canada.
> > You can no longer link directly to PDF documents. You will need to go to
> > the registered website where the seal is provided and click on the seal
> to
> > obtain the document (e.g. audit report).
> > Also, we are now enforcing the domain requirement when a seal is opened.
> > Domain enforcement is essential to the program to prevent fraudulent use.
> > It ensures that the WebTrust seals will only function on the certificate
> > authority’s websites.
> > If a seal is opened from a non-registered domain or other source (e.g.
> > email, internal lists, etc.) the seal will not load and will display a
> > notice indicating that the domain is not valid.
> > “”
> >
> > Therefore, for the foreseeable future, please do the following when
> > creating an Audit Case in the CCADB for WebTrust audits.
> >
> > 1) Make the PDFs of the audit statements available directly on your CA's
> > website.
> > OR
> > Upload your audit statement PDF files to Bugzilla, as described here:
> > https://ccadb.org/cas/fields#uploading-documents
> >
> > 2) For the audit statement link in your CCADB Audit Case either provide
> > the URL to the PDF on your CA's website, or use the link to the document
> in
> > Bugzilla.
> >
> > 3) Add a Audit Case Comment to indicate the URL where the WebTrust seals
> > may be found on your CA’s website.
> >
> > 4) When you run the Audit Letter Validation (ALV), you can ignore the
> > “Cleaned=Fail” ALV result. I will check the seal on your website
> manually,
> > and add a comment to the Audit Case.
> >
> >
> > Also, the cert.webtrust.org audit links that are currently in the root
> > cert records and the intermediate cert records in the CCADB no longer
> work
> > either. Fortunately we started archiving audit statements this year. So
> you
> > can scroll down to the “File Archive…” section of the record, and you
> will
> > be able to find the stored audit pdfs.
> >
> > Thanks,
> > Kathleen
> >
> >
> > ___
> > 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: How to submit WebTrust audits in CCADB

[Ryan Sleevi via dev-security-policy]

Thanks for the update, Kathleen.

This is truly unfortunate, and unquestionably does harm to the value and
brand of the WebTrust Seal, rather than provide value.

On Thu, Aug 9, 2018 at 7:19 PM, Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> All,
>
> In their effort to better protect WebTrust seals, CPA Canada has made it
> so we can no longer access WebTrust pdf files directly from the CCADB.
>
> I received the following response when inquiring about this.
> “”
> Thank you for contacting Chartered Professional Accountants of Canada.
> You can no longer link directly to PDF documents. You will need to go to
> the registered website where the seal is provided and click on the seal to
> obtain the document (e.g. audit report).
> Also, we are now enforcing the domain requirement when a seal is opened.
> Domain enforcement is essential to the program to prevent fraudulent use.
> It ensures that the WebTrust seals will only function on the certificate
> authority’s websites.
> If a seal is opened from a non-registered domain or other source (e.g.
> email, internal lists, etc.) the seal will not load and will display a
> notice indicating that the domain is not valid.
> “”
>
> Therefore, for the foreseeable future, please do the following when
> creating an Audit Case in the CCADB for WebTrust audits.
>
> 1) Make the PDFs of the audit statements available directly on your CA's
> website.
> OR
> Upload your audit statement PDF files to Bugzilla, as described here:
> https://ccadb.org/cas/fields#uploading-documents
>
> 2) For the audit statement link in your CCADB Audit Case either provide
> the URL to the PDF on your CA's website, or use the link to the document in
> Bugzilla.
>
> 3) Add a Audit Case Comment to indicate the URL where the WebTrust seals
> may be found on your CA’s website.
>
> 4) When you run the Audit Letter Validation (ALV), you can ignore the
> “Cleaned=Fail” ALV result. I will check the seal on your website manually,
> and add a comment to the Audit Case.
>
>
> Also, the cert.webtrust.org audit links that are currently in the root
> cert records and the intermediate cert records in the CCADB no longer work
> either. Fortunately we started archiving audit statements this year. So you
> can scroll down to the “File Archive…” section of the record, and you will
> be able to find the stored audit pdfs.
>
> Thanks,
> Kathleen
>
>
> ___
> 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

How to submit WebTrust audits in CCADB

[Kathleen Wilson via dev-security-policy]

All,

In their effort to better protect WebTrust seals, CPA Canada has made it 
so we can no longer access WebTrust pdf files directly from the CCADB.


I received the following response when inquiring about this.
“”
Thank you for contacting Chartered Professional Accountants of Canada.
You can no longer link directly to PDF documents. You will need to go to 
the registered website where the seal is provided and click on the seal 
to obtain the document (e.g. audit report).
Also, we are now enforcing the domain requirement when a seal is opened. 
 Domain enforcement is essential to the program to prevent fraudulent 
use. It ensures that the WebTrust seals will only function on the 
certificate authority’s websites.
If a seal is opened from a non-registered domain or other source (e.g. 
email, internal lists, etc.) the seal will not load and will display a 
notice indicating that the domain is not valid.

“”

Therefore, for the foreseeable future, please do the following when 
creating an Audit Case in the CCADB for WebTrust audits.


1) Make the PDFs of the audit statements available directly on your CA's 
website.

OR
Upload your audit statement PDF files to Bugzilla, as described here:
https://ccadb.org/cas/fields#uploading-documents

2) For the audit statement link in your CCADB Audit Case either provide 
the URL to the PDF on your CA's website, or use the link to the document 
in Bugzilla.


3) Add a Audit Case Comment to indicate the URL where the WebTrust seals 
may be found on your CA’s website.


4) When you run the Audit Letter Validation (ALV), you can ignore the 
“Cleaned=Fail” ALV result. I will check the seal on your website 
manually, and add a comment to the Audit Case.



Also, the cert.webtrust.org audit links that are currently in the root 
cert records and the intermediate cert records in the CCADB no longer 
work either. Fortunately we started archiving audit statements this 
year. So you can scroll down to the “File Archive…” section of the 
record, and you will be able to find the stored audit pdfs.


Thanks,
Kathleen


___
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

[Robin Alden via dev-security-policy]

Hi Hanno,

The certificate has been revoked.

We're in the process of migrating our email addresses to all be on comodoca.com 
and the emails for ssl_abuse@ got directed away from the monitored queue we 
have in place for it.  We didn't notice it straight away because there are some 
other variants of the abuse email addresses which are still active and were 
still receiving mail.
This was corrected and this certificate was revoked after checking the key.

Regards

Robin Alden
Comodo CA Ltd.

> -Original Message-
> From: Hanno Böck 
> Sent: 08 August 2018 15:18
> Cc: Alex Cohn ; summern1...@gmail.com; mozilla-
> dev-security-policy@lists.mozilla.org; #SSL_ABUSE
> 
> Subject: Re: localhost.megasyncloopback.mega.nz private key in client
> 
> On Sun, 5 Aug 2018 15:23:42 -0500
> Alex Cohn via dev-security-policy
>  wrote:
> 
> > The certificate [1] in the GitHub link you posted was issued by
> > Comodo, not by GeoTrust. The two share a private key, though, so both
> > the Comodo and GeoTrust certs should be considered compromised at this
> > point. I've added the Comodo-issued cert to several CT logs for
> > tracking, and I'm CCing ssl_ab...@comodoca.com for followup.
> 
> 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/
> 
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


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

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

[Tim Hollebeek via dev-security-policy]

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  On
> Behalf Of Tim Hollebeek via dev-security-policy
> Sent: Thursday, August 9, 2018 10:26 AM
> To: r...@sleevi.com
> Cc: Alex Cohn ; 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 
> Sent: Thursday, August 9, 2018 7:15 AM
> To: Tim Hollebeek 
> Cc: Alex Cohn ; 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
> 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
> >  >  > 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   > 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  pol...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy
> 
> 



smime.p7s
Description: S/MIME cryptographic signature
___

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

[Tim Hollebeek via dev-security-policy]

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  
Sent: Thursday, August 9, 2018 7:15 AM
To: Tim Hollebeek 
Cc: Alex Cohn ; 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 
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   > 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   > 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

 



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

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

[Hanno Böck via dev-security-policy]

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

[Wayne Thayer via dev-security-policy]

The proposed "Revocation Timeline Extension" ballot (formerly #213, soon to
become #SC6) [1] includes the following:

The CA SHALL provide Subscribers, Relying Parties, Application Software
Suppliers, and other third parties with clear instructions for reporting
suspected Private Key Compromise, Certificate misuse, or other types of
fraud, compromise, misuse, inappropriate conduct, or any other matter
related to Certificates. The CA SHALL publicly disclose the instructions
through a readily accessible online means and in section 1.5.2 of their CPS.
- Wayne

[1]
https://github.com/cabforum/documents/compare/master...wthayer:patch-1?short_path=7f6d14a#diff-7f6d14a20e7f3beb696b45e1bf8196f2

On Thu, Aug 9, 2018 at 7:41 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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> 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>
> > 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  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
>
___
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

Re: GoDaddy Revocations Due to a Variety of Issues

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 9, 2018 at 8:24 AM, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Fri, 20 Jul 2018 21:38:45 -0700
> Peter Bowen via dev-security-policy
>  wrote:
>
> >  https://crt.sh/?id=294808610=zlint,cablint is one of the
> > certificates.  It is not clear to me that there is an error here.
> > The DNS names in the SAN are correctly encoded and the Common Name in
> > the subject has one of the names found in the SAN.  The Common Name
> > contains a DNS name that is the U-label form of one of the SAN
> > entries.
> >
> > It is currently undefined if this is acceptable or unacceptable for
> > certificates covered by the BRs.  I put a CA/Browser Forum ballot
> > forward a while ago to try to clarify it was not acceptable, but it
> > did not pass as several CAs felt it was not only acceptable but is
> > needed and desirable.
>
> It would be helpful if any such CAs can tell us why this was "needed and
> desirable" with actual examples.
>
> Since the CN field in Web PKI certs always contains information
> duplicated from a field that has been better defined for decades I'm
> guessing in most cases the cause is crappy software. But if we know
> which software is crappy we can help get that fixed rather than
> muddling along forever.


This information is readily available in the discussions for CA/Browser
Forum Ballot 202 -
https://cabforum.org/2017/07/26/ballot-202-underscore-wildcard-characters/
- which would have unambiguously specified and clarified this.

The following CAs voted against: Buypass, CFCA, DocuSign France, Entrust,
GDCA, GlobalSign, SHECA

Buypass - https://cabforum.org/pipermail/public/2017-July/011744.html
CFCA - https://cabforum.org/pipermail/public/2017-July/011733.html
Docusign - https://cabforum.org/pipermail/public/2017-July/011708.html
Entrust - https://cabforum.org/pipermail/public/2017-July/011747.html
GlobalSign - https://cabforum.org/pipermail/public/2017-July/011692.html
GDCA - https://cabforum.org/pipermail/public/2017-July/011736.html
SHECA - https://cabforum.org/pipermail/public/2017-July/011737.html

You can see not all objections are strictly related to that matter at hand,
but hopefully it provides you further information.
___
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

[Ryan Sleevi via dev-security-policy]

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> 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 
> 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  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: GoDaddy Revocations Due to a Variety of Issues

[Nick Lamb via dev-security-policy]

On Fri, 20 Jul 2018 21:38:45 -0700
Peter Bowen via dev-security-policy
 wrote:

>  https://crt.sh/?id=294808610=zlint,cablint is one of the
> certificates.  It is not clear to me that there is an error here.
> The DNS names in the SAN are correctly encoded and the Common Name in
> the subject has one of the names found in the SAN.  The Common Name
> contains a DNS name that is the U-label form of one of the SAN
> entries.
> 
> It is currently undefined if this is acceptable or unacceptable for
> certificates covered by the BRs.  I put a CA/Browser Forum ballot
> forward a while ago to try to clarify it was not acceptable, but it
> did not pass as several CAs felt it was not only acceptable but is
> needed and desirable.

It would be helpful if any such CAs can tell us why this was "needed and
desirable" with actual examples.

Since the CN field in Web PKI certs always contains information
duplicated from a field that has been better defined for decades I'm
guessing in most cases the cause is crappy software. But if we know
which software is crappy we can help get that fixed rather than
muddling along forever.
___
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

[Tim Hollebeek via dev-security-policy]

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  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  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


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