Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[Wayne Thayer via dev-security-policy]

On Fri, Mar 2, 2018 at 3:47 PM, David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 3/2/2018 2:05 PM, Wayne Thayer wrote [in part]:
>
> [snipped]
>
> NOTE: The fact that I have snipped some of the items under "==Bad=="
> does not mean I consider them unimportant. However, the items on
> which I comment I consider to be most important.
>
> > ==Bad==
> > * The inclusion request references a much older CPS [3] that doesn't list
> > the 2016 versions of these roots or comply with current policies. I only
> > reviewed the newer CPS [5], but this CPS (section 1.2.1) doesn't cover
> the
> > older roots that are currently included. I believe this is a compliance
> > issue with the currently included AC Camerfirma roots.
>
> Is the above not sufficient to terminate the public review?
>
> My comment may be confusing. The newer CPS specifically covers the roots
we're discussing, and the CPS is compliant with policy with the exception
of things noted in other comments. I would like Camerfirma to comment on my
conclusion about the older CPS and it's applicability to the older roots.

[snipped]
>
> > * Last year, Camerfirma signed a contract with StartCom as a delegated
> RA.
> > While I don’t believe the Startcom distrust plan [2] specifically forbade
> > this, it was found that Camerfirma was not performing domain validation
> on
> > the OV certificates [4] as required by the BRs.
>
> I would strongly suggest that further action be deferred until the cited
> contract can be confirmed to have been terminated.
>
> I would like to hear from Camerfirma on this, but StartCom did announce
that they have "terminated the company":
https://groups.google.com/d/msg/mozilla.dev.security.policy/DxbMjAN7VbY/VJ0W9LQhBwAJ


> [snipped]
>
> > * There are a few published, misissued, and currently unrevoked
> > certificates in the CCR2016 hierarchy:
> > https://crt.sh/?caid=50473&opt=cablint,zlint,x509lint&;
> minNotBefore=2011-01-01
>
> If Camerfirma had been already approved and its root added to the RSS
> database, would not the above item be sufficient to remove that root?
>
> It would be treated as an incident, but in isolation seems unlikely to
rise to the level of root removal.

[snipped]
> --
> David E. Ross
> 
>
> President Trump:  Please stop using Twitter.  We need
> to hear your voice and see you talking.  We need to know
> when your message is really your own and not your attorney's.
> ___
> 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: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[David E. Ross via dev-security-policy]

On 3/2/2018 2:05 PM, Wayne Thayer wrote [in part]:

[snipped]

NOTE: The fact that I have snipped some of the items under "==Bad=="
does not mean I consider them unimportant. However, the items on
which I comment I consider to be most important.

> ==Bad==
> * The inclusion request references a much older CPS [3] that doesn't list
> the 2016 versions of these roots or comply with current policies. I only
> reviewed the newer CPS [5], but this CPS (section 1.2.1) doesn't cover the
> older roots that are currently included. I believe this is a compliance
> issue with the currently included AC Camerfirma roots.

Is the above not sufficient to terminate the public review?

[snipped]

> * Last year, Camerfirma signed a contract with StartCom as a delegated RA.
> While I don’t believe the Startcom distrust plan [2] specifically forbade
> this, it was found that Camerfirma was not performing domain validation on
> the OV certificates [4] as required by the BRs.  

I would strongly suggest that further action be deferred until the cited
contract can be confirmed to have been terminated.

[snipped]

> * There are a few published, misissued, and currently unrevoked
> certificates in the CCR2016 hierarchy:
> https://crt.sh/?caid=50473&opt=cablint,zlint,x509lint&minNotBefore=2011-01-01

If Camerfirma had been already approved and its root added to the RSS
database, would not the above item be sufficient to remove that root?

[snipped]
-- 
David E. Ross


President Trump:  Please stop using Twitter.  We need
to hear your voice and see you talking.  We need to know
when your message is really your own and not your attorney's.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[Wayne Thayer via dev-security-policy]

This request is for inclusion of the Camerfirma CHAMBERS OF COMMERCE ROOT -
2016 (CCR2016) and GLOBAL CHAMBERSIGN ROOT - 2016 (GCSR2016) as documented
in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=986854

* BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=8907536

* Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8839575

* Root Certificate Download URL:
http://www.camerfirma.com/en/area-de-usuario/jerarquia-politicas-y-practicas-de-certificacion/

* CP/CPS:
http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_eidas_v_1_2_1_EN.pdf

* This request is to turn on the Websites and Email trust bits. EV
treatment is requested.

* EV Policy OIDs: 1.3.6.1.4.1.17326.10.16.3.5.1 (CCR2016),
1.3.6.1.4.1.17326.10.8.12.1.2 (GCSR2016)

* Test Websites
  * CCR2016:
https://cev.camerfirma.com expired
https://cevrv.camerfirma.com revoked
https://cevok.camerfirma.com valid

  * GCSR2016:
https://csev.camerfirma.com expired
https://csevrv.camerfirma.com revoked
https://csevok.camerfirma.com valid

* CRL URLs:
CCR2016: http://crl.camerfirma.com/chambersofcommerceroot-2016.crl
GCSR2016: http://crl.camerfirma.com/globalchambersignroot-2016.crl

* OCSP URLs:
http://ocsp.camerfirma.com/

* Audit: Annual audits are performed by AUREN according to the WebTrust for
CA, EV, and BR audit criteria.
WebTrust: https://bugzilla.mozilla.org/attachment.cgi?id=8890729
BR: https://bugzilla.mozilla.org/attachment.cgi?id=8890727
EV: https://bugzilla.mozilla.org/attachment.cgi?id=8890726


I’ve reviewed the CPS, BR Self Assessment, and related information for the
CCR2016 and GCSR2016 inclusion requests that are being tracked in this bug
[1] and have the following comments:

==Good==
* Subordinate CAs issued under these roots are constrained to specific
purposes via EKU.
* Audit reports include English translations and contain most of the
required information, with the exception of SHA-256 fingerprints and the
full address of the auditor.
* The CA hierarchies and applicable usages and policies are clearly
described in section 1.2 of the CPS.

==Meh==
* Camerfirma has had a number of recent compliance issues as listed below:
Resolved:
* Non-BR-compliant OCSP responders:
https://bugzilla.mozilla.org/show_bug.cgi?id=1426233
* CAA checking failure:
https://bugzilla.mozilla.org/show_bug.cgi?id=1420871
* Duplicate SANs and without localityName or stateOrProvinceName:
https://bugzilla.mozilla.org/show_bug.cgi?id=1357067
* Invalid DNS Names:
https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 (just resolved today)
Still Open:
* Non-printable characters in OU field:
https://bugzilla.mozilla.org/show_bug.cgi?id=1431164 (this issue was
reported by Camerfirma)
* CPS [5] section 1.2.1.1 appears to exempt test certificates from BR
requirements.
* Section 3.1.8.2.2 of the CPS implies that CAA checking is done manually.
While this isn’t forbidden, it is easily susceptible to errors.
* CPS section 1.2.1.4.1.3 states that the GCSR2016 “is only used for the
purpose of carrying out the accreditation processes with different
browsers.” We recently decided to relax the requirements for inclusion, but
this statement does imply that there is no value to Mozilla users in
enabling the websites trust bit for this root.
* CPS section 1.5.5 indicates that delegated RAs are permitted, but it does
not clearly indicate that domain validation functions may not be delegated.
* CPS section 2.5.3 states that “Camerfirma currently offers the OCSP
service free-of-charge but reserves the right to invoice for these
services.” If OCSP service were to be blocked for all but paying users, I
believe that would be a BR violation.

==Bad==
* The inclusion request references a much older CPS [3] that doesn't list
the 2016 versions of these roots or comply with current policies. I only
reviewed the newer CPS [5], but this CPS (section 1.2.1) doesn't cover the
older roots that are currently included. I believe this is a compliance
issue with the currently included AC Camerfirma roots.
* I am unable to locate a BR audit for the GCSR2016, but the websites trust
bit has been requested. I first thought that this root was not intended for
serverAuth, but section 1.2.1.4 of the CPS indicates that there is an “AC
CAMERFIRMA GLOBAL FOR WEBSITES” subordinate CA that chains to this root.
Both roots are covered by the latest EV audit.
* Last year, Camerfirma signed a contract with StartCom as a delegated RA.
While I don’t believe the Startcom distrust plan [2] specifically forbade
this, it was found that Camerfirma was not performing domain validation on
the OV certificates [4] as required by the BRs.
* The BR section 2.2 requirement that “The CA SHALL publicly give effect to
these Requirements and represent that it will adhere to the latest
published version” is not clearly stated in the CPS. Also, the final
paragraph of section 1.2 implies that the CPS takes precedence over BR
requir

Re: Trustico code injection

[randomsyseng--- via dev-security-policy]

> Trustico have assured us that the private key
> could not have been compromised.  

Did they elaborate on how they came to that "could not have been" conclusion?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[chris--- via dev-security-policy]

That's not what Trustico are saying in their fulfilment emails (received during 
the purchase of a Trustico® certificate through Comodo CA this morning):

'If you chose to have us generate your CSR during the ordering process, you 
will need to contact us for a copy of your corresponding Private Key. Your 
Private Key is not included within this e-mail for security reasons.

If you decided to provide your own CSR, we don't have access to your Private 
Key. It will already reside on your device or server.'

'If you chose to have us generate your CSR during the ordering process, your 
Private Key will only be saved within our systems for the next 14 days.'

On Friday, 2 March 2018 17:29:36 UTC, Rob Stradling  wrote:
> We also asked Trustico to cease offering any tools to generate and/or 
> retain customer private keys.  They have complied with this request and 
> have confirmed that they do not intend to offer any such tools again in 
> the future.
> 
> Trustico have also confirmed to us that they were not, and are not, in 
> possession of the private keys that correspond to any of the 
> certificates that they have requested for their customers through Comodo CA.
> 
> On 02/03/18 15:25, Rich Smith via dev-security-policy wrote:
> > Comodo CA has investigated the reports posted to this list relating to the
> > suspected compromise of the private key corresponding to
> > https://crt.sh/?id=206535041.  Trustico have assured us that the private key
> > could not have been compromised.  However, since it will be hard to convince
> > everyone that this is the case, Trustico have agreed to obtain a replacement
> > certificate with a new keypair.  Once that new certificate has been
> > installed, Comodo CA will revoke https://crt.sh/?id=206535041.
> > 
> > Regards,
> > Rich Smith
> > Sr. Compliance Manager
> > Comodo CA
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> ComodoCA.com

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Wayne Thayer via dev-security-policy]

On Fri, Mar 2, 2018 at 11:58 AM, Doug Beattie 
wrote:

> Hi Wayne,
>
> Is the Firefox 60 update in May the same as the combination of the April
> and October Chrome updates, in that all Symantec certificates will be
> untrusted on this date (5 months before Chrome)?
>
> Sorry for not making that clear Doug. Firefox is implementing the
consensus plan as originally described, meaning that Firefox 60 only blocks
Symantec certificates issued prior to 1-June 2016. We plan to remove that
restriction in Firefox 63.

Doug
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Ian Carroll via dev-security-policy]

(re-sending to list)

> We also asked Trustico to cease offering any tools to generate and/or
retain customer private keys.

Does Comodo intend to standardize a policy against this? GoGetSSL has a
tool like this in their customer panel and I’m sure there are more.

On Fri, Mar 2, 2018 at 12:29 PM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> We also asked Trustico to cease offering any tools to generate and/or
> retain customer private keys.  They have complied with this request and
> have confirmed that they do not intend to offer any such tools again in
> the future.
>
> Trustico have also confirmed to us that they were not, and are not, in
> possession of the private keys that correspond to any of the
> certificates that they have requested for their customers through Comodo
> CA.
>
> On 02/03/18 15:25, Rich Smith via dev-security-policy wrote:
> > Comodo CA has investigated the reports posted to this list relating to
> the
> > suspected compromise of the private key corresponding to
> > https://crt.sh/?id=206535041.  Trustico have assured us that the
> private key
> > could not have been compromised.  However, since it will be hard to
> convince
> > everyone that this is the case, Trustico have agreed to obtain a
> replacement
> > certificate with a new keypair.  Once that new certificate has been
> > installed, Comodo CA will revoke https://crt.sh/?id=206535041.
> >
> > Regards,
> > Rich Smith
> > Sr. Compliance Manager
> > Comodo CA
> --
> Rob Stradling
> Senior Research & Development Scientist
> ComodoCA.com
> ___
> 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: Mozilla’s Plan for Symantec Roots

[Doug Beattie via dev-security-policy]

Hi Wayne,

Is the Firefox 60 update in May the same as the combination of the April and 
October Chrome updates, in that all Symantec certificates will be untrusted on 
this date (5 months before Chrome)?

Doug

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Wayne
> Thayer via dev-security-policy
> Sent: Friday, March 2, 2018 1:12 PM
> Cc: mozilla-dev-security-policy 
> 
> Subject: Re: Mozilla’s Plan for Symantec Roots
> 
> Update:
> 
> Mozilla is moving forward with our implementation of the consensus plan for
> Symantec roots [1]. With the exception of whitelisted subordinate CAs using
> the keys listed on the wiki [2], Symantec certificates are now blocked by
> default on Nightly builds of Firefox. The preference
> "security.pki.distrust_ca_policy" can be used to override these changes. A
> custom error message is also being implemented [3]. These changes are part of
> Firefox 60, which is scheduled to be released in May [4].
> 
> There are still a lot of websites using Symantec certificates, but the number 
> are
> declining rapidly. Lists of affected sites and regularly updated metrics are
> available via bug 1434300 [5].
> 
> - Wayne
> 
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/FLHRT79e3XE/
> 90qkf8jsAQAJ
> [2] https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1441223
> [4] https://wiki.mozilla.org/RapidRelease/Calendar
> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1434300
> ___
> 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: Trustico code injection

[Rich Smith via dev-security-policy]

https://crt.sh/?id=206535041 is now revoked.
Regards,
Rich Smith


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: Mozilla’s Plan for Symantec Roots

[Wayne Thayer via dev-security-policy]

Update:

Mozilla is moving forward with our implementation of the consensus plan for
Symantec roots [1]. With the exception of whitelisted subordinate CAs using
the keys listed on the wiki [2], Symantec certificates are now blocked by
default on Nightly builds of Firefox. The preference
"security.pki.distrust_ca_policy" can be used to override these changes. A
custom error message is also being implemented [3]. These changes are part
of Firefox 60, which is scheduled to be released in May [4].

There are still a lot of websites using Symantec certificates, but the
number are declining rapidly. Lists of affected sites and regularly updated
metrics are available via bug 1434300 [5].

- Wayne

[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/FLHRT79e3XE/
90qkf8jsAQAJ
[2] https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1441223
[4] https://wiki.mozilla.org/RapidRelease/Calendar
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1434300
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Rob Stradling via dev-security-policy]

We also asked Trustico to cease offering any tools to generate and/or 
retain customer private keys.  They have complied with this request and 
have confirmed that they do not intend to offer any such tools again in 
the future.


Trustico have also confirmed to us that they were not, and are not, in 
possession of the private keys that correspond to any of the 
certificates that they have requested for their customers through Comodo CA.


On 02/03/18 15:25, Rich Smith via dev-security-policy wrote:

Comodo CA has investigated the reports posted to this list relating to the
suspected compromise of the private key corresponding to
https://crt.sh/?id=206535041.  Trustico have assured us that the private key
could not have been compromised.  However, since it will be hard to convince
everyone that this is the case, Trustico have agreed to obtain a replacement
certificate with a new keypair.  Once that new certificate has been
installed, Comodo CA will revoke https://crt.sh/?id=206535041.

Regards,
Rich Smith
Sr. Compliance Manager
Comodo CA

--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Wayne Thayer via dev-security-policy]

Thanks everyone for your input on this topic. The consensus seems to be
that allowing WebExtensions to muck with certificate validation decisions
is a bad idea. The bug [1] has been updated with that sentiment and a link
to this discussion.

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1435951
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Trustico code injection

[Rich Smith via dev-security-policy]

Comodo CA has investigated the reports posted to this list relating to the
suspected compromise of the private key corresponding to
https://crt.sh/?id=206535041.  Trustico have assured us that the private key
could not have been compromised.  However, since it will be hard to convince
everyone that this is the case, Trustico have agreed to obtain a replacement
certificate with a new keypair.  Once that new certificate has been
installed, Comodo CA will revoke https://crt.sh/?id=206535041.

Regards,
Rich Smith
Sr. Compliance Manager
Comodo CA


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: Trustico code injection

[Todd Johnson via dev-security-policy]

> The code injection occurred on an interface they had to check the
> certificate of an arbitrary server. When 127.0.0.1 was used, the
> trustico.com certificate was returned. That means the local web server
> was handling TLS, not a remote load balancer solution (unless somehow
> 127.0.0.1 was forwarding to a remote host, which doesn't really make any
> sense).
>
> --
> Hector Martin "marcan" (mar...@marcan.st)
> Public Key: https://mrcn.st/pub


Did *anyone* capture this information in a way that can be proven?

While I personally would not trust any content from either hostname, the
Twitter post referenced earlier is not sufficient proof of key compromise.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Lewis Resmond via dev-security-policy]

Not in my opinion. If my house is burning, I expect someone to call the fire 
department even if I am not aware/convinced that the house is burning.
The fact that they disabled their website is evidence that the Twitter posts 
were no fake.

Am Donnerstag, 1. März 2018 20:53:16 UTC+1 schrieb Tim Shirley:
> That's jumping the gun a bit.  First of all they'd have to be made aware of 
> the suspected compromise before the 24 hour clock would start.  And then 
> they'd need to be convinced that it actually was compromised.  Since the 
> server has apparently been taken down, they wouldn't be able to verify these 
> claims themselves and I would certainly hope a CA wouldn't take such an 
> action based only on unverified claims on Twitter.
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Comodo and Trustico (was Re: Trustico code injection)

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

On Fri, 2 Mar 2018 16:10:52 +0900
Hector Martin 'marcan' via dev-security-policy
 wrote:

> And what does Comodo think of all of this?

I'd like to second this.

When I wrote the original mail in this thread I considered adding
questions to Comodo, but I thought it's so obvious and Comodo people
will see this anyway that it's not necessary.

But yesterday, hours after the whole Trustico thing was unfolding,
Comodo's Twitter account sent out tweets indicating that they're proud
to be the new partner of Trustico:
https://twitter.com/Comodo_SSL/status/969302576649908226

So hereby I'd like to ask Comodo:
* Do you have any security vetting of your certificate reseller
  partners? Do you expect them to follow good security practice?
* Do you believe - given the events of recent days - that Trustico
  follows good security practice?

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