Identrust Commercial Root CA 1 EV Request

2018-09-18 Thread Wayne Thayer via dev-security-policy
This request is to enable EV treatment for the Identrust Commercial Root CA
1 as documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1339292

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

* Summary of Information Gathered and Verified:
https://bug1339292.bmoattachments.org/attachment.cgi?id=8965525

* Root Certificate Download URL:
https://bugzilla.mozilla.org/attachment.cgi?id=8473319

CP/CPS:
** CP:
https://www.identrust.com/sites/default/files/resources/IdenTrust_TrustID_Certificate_Policy_V4.1_08172018.pdf
** CPS:
https://www.identrust.com/sites/default/files/resources/IdenTrust_TrustID_Certificate_Practices_Statement_V4.1_08172018.pdf

* This root is already included with Websites and Email trust bits. EV
treatment is requested.
** EV Policy OID: 2.23.140.1.1
** Original inclusion request:
https://bugzilla.mozilla.org/show_bug.cgi?id=1037590

* Test Websites:
** Valid: https://ev-valid.identrustssl.com/
** Expired: https://ev-expired.identrustssl.com/
** Revoked: https://ev-revoked.identrustssl.com/

* CRL URL: http://validation.identrust.com/trustidcaa52.crl
* OCSP URL: http://commercial.ocsp.identrust.com/

* Audit: Annual audits are performed by Schellman according to the WebTrust
for CA, BR, and EV audit criteria.
** WebTrust: https://cert.webtrust.org/ViewSeal?id=2331
** BR: https://www.cpacanada.ca/webtrustseal?sealid=2334
** EV: https://www.cpacanada.ca/webtrustseal?sealid=2335

I’ve reviewed the CPS, BR Self Assessment, and related information for the
Identrust Commercial Root CA 1 EV request that is being tracked in this bug
and have the following comments:

==Good==
* Identrust’s audits prior to 2016 don’t list specific roots, but this root
appears to have been audited back to its creation in 2014.
* In their latest BR audit statement [1], Identrust’s auditor includes an
“Emphasis on Matters” section in which they list four BR violations
disclosed by Identrust. All of these issues were previously known and are
included in comments below.
* CPS section 1.4.2 expressly prohibits the use of Identrust certificates
for MitM.

==Meh==
* There are a few misissued certs documented under this root [2][3]. All
appear to be expired or revoked.
* Identrust was the subject of two compliance bugs last year [4][5]. Both
have been resolved, but it was noted that Identrust was slow to respond to
Mozilla’s questions.
* Three intermediate certificates have been disclosed under this root, but
the EV audit explicitly lists only the TrustID Server CA A52 as in-scope.
The A12 intermediate is constrained by EKU to emailProtection, but the Booz
Allen Hamilton BA CA 01 is not. The Booz Allen Hamilton BA CA 01 does
contain a set of policy OIDs that exclude Identrust’s EV policy, but that
does not satisfy section 3.1.2 of Mozilla policy. However, Firefox will not
display an EV indication if the intermediate certificate’s
certificatePolicies extension does not include either anyPolicy or the CAs
or CABF EV policy OID, so I believe this is a problem with our policy.
* Identrust’s CPS section 1.3.2 allow delegation of the RA function but
doesn’t explicitly state that domain validation must be performed by
Identrust. The CPS does state that it complies with the BRs which forbid
delegation of domain validation.
* CPS section 2.3 states that the PMA updates the CPS on an annual basis to
include the most recent CAB Forum requirements, but Mozilla expects CPS
updates to happen whenever required by changes to either CAB Forum
requirements or Mozilla policy. However, both the CP and CPS have been
updated more frequently in the past year.
* Typo in CPS section 6.9 heading: “ENGINREERING”

==Bad==
* Identrust had an open compliance bug for improper encoding of 6 wildcard
certificates [6]. Remediation for this bug included the implementation of
pre-issuance linting by the end of Q3, more than 6 months after the issue
was reported. Identrust also chose to wait a week before revoking all of
the misissued certificates. This could be considered another example of
Identrust being slow to respond, but they did confirm that pre-issuance
linting was deployed in August, well ahead of their goal.
* The version of the CPS that I initially reviewed (4.0) describes a number
of methods of domain name validation in section 3.2.10.5 that do not appear
to fully comply with the BRs. This was corrected in the current version,
but one of the methods listed is BR 3.2.2.4.10, which contains a known
vulnerability [7].
* Two of the Identrust policy OIDs listed in the Booz Allen Hamilton BA CA
0 intermediate certificate were not documented in Identrust’s CP or CPS,
but have been added to the latest version.
* Section 3.2 of the CPS states that “All documents and data provided for
verifying the Server Certificate must not be used by the RA if the document
or data was obtained 39 or more months prior to the Issuance of the
Certificate or in the case of EV SSL, 13 months prior to issuance.”. 

Re: Google Trust Services Root Inclusion Request

2018-09-18 Thread Matthew Hardeman via dev-security-policy
A few thoughts, inlined below...

On Monday, September 17, 2018 at 6:42:29 PM UTC-5, Jake Weisz wrote:
> I guess under this logic, I withdraw my protest. As you say, Google
> could simply start using these certificates, and Mozilla executives
> would force you to accept them regardless of any policy violations in
> order to keep people using Firefox. This whole process appears to
> mostly just be a veneer of legitimacy on a process roughly akin to the
> fair and democratic election of Vladimir Putin. :| As long as Google
> remains legally answerable to no authority and an effective monopoly
> in half a dozen markets, there is roughly no point for Mozilla to
> maintain a CA policy: It should simply use Chrome's trusted store.

Your summation here does not logically follow.  Yes, it's true that with a 
giant installed base of Chrome and the ability to auto-update it, Google can 
more or less arbitrarily insert new trust into their browser with impunity.

Having said that, they have historically not done so.  In fact -- and I think 
this may be changing --  for now, Chrome on most platforms delegates initial 
trust decision to the OS's corresponding trust store.  Chrome on MacOS / Chrome 
on IOS use the native APIs and Apple trust store to determine initial trust, 
then Chrome applies further logic to downgrade trust of certain scenarios 
(Symantec descendant certs, etc.)  Chrome on Windows presently uses the Windows 
APIs and Windows trust store.  It has been suggested that Chrome ultimately 
intends to maintain a formal Chrome trust store, but this is not the case today.

Today this means that to be trusted on Windows, even in Chrome, you have to be 
in the Microsoft root program.  To be trusted on Apple platforms, even in 
Chrome, you have to be in the Apple root program.

To date, no one has caught Chrome trusting things it shouldn't by way of an 
automated update.  If they tried to do that without good explanation, it would 
be easily caught at the level of scale that Chrome is used at.

It is undeniable that the various titans of the internet wield enormous power 
over the software and infrastructure of the internet.  Historically, Google is 
a significant enough contributor to Mozilla financially that it's hard to 
imagine that Mozilla would deny them much even if making Firefox trust 
everything that Chrome trusts didn't become competitively necessary.

Nevertheless, even if Google were totally exempt from the standards for 
inclusion and even if Google didn't act honorably in their inclusions (though 
nothing has suggested this), your argument that Mozilla shouldn't bother with a 
trust store / root program is illogical.  Even if Google got a truly free pass, 
someone still has to police the many others who want to be in the trust program.

> Google's explanation in their announcement seems to confirm my
> statement: That buying roots from GlobalSign is effectively
> backdooring the CA process and making their certificates work in
> products which would not otherwise trust them.

Actually, Google took a bit of heat from the community and the Mozilla root 
program regarding the acquisitions of that root and of the transfer of the 
roots to Google.  While ultimately no action was taken against Google or 
Globalsign as a direct result of those transfers, the transfers did evidence 
holes in the program's policies and further revisions were made and guidance 
given for any future transfers.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Audit Reminder Email Summary

2018-09-18 Thread Kathleen Wilson via dev-security-policy

 Forwarded Message 
Subject: Summary of September 2018 Audit Reminder Emails
Date: Tue, 18 Sep 2018 19:00:14 + (GMT)

Mozilla: Audit Reminder
Root Certificates:
   AC Raíz Certicámara S.A.
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221203

Audit Statement Date: 2017-08-09
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Certinomis - Root CA
Standard Audit: 
https://bug937589.bmoattachments.org/attachment.cgi?id=8898169

Audit Statement Date: 2017-07-24
BR Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
BR Audit Statement Date: 2017-07-24
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   E-Tugra Certification Authority
Standard Audit: 
https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2017.pdf

Audit Statement Date: 2017-09-09
BR Audit: 
https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2017.pdf

BR Audit Statement Date: 2017-09-09
EV Audit: 
https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2017.pdf

EV Audit Statement Date: 2017-09-09
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Go Daddy Class 2 CA
   Go Daddy Root Certificate Authority - G2
   Starfield Class 2 CA
   Starfield Root Certificate Authority - G2
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221042

Audit Statement Date: 2017-08-31
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221042

BR Audit Statement Date: 2017-08-31
EV Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221042

EV Audit Statement Date: 2017-08-31
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   ACCVRAIZ1
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221168

Audit Statement Date: 2017-07-28
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221169

BR Audit Statement Date: 2017-07-28
CA Comments: Per CA request, Root CA Generalitat Valenciana will be 
removed via https://bugzilla.mozilla.org/show_bug.cgi?id=1272158




Mozilla: Audit Reminder
Root Certificates:
   Izenpe.com
Standard Audit: 
http://www.izenpe.eus/contenidos/informacion/auditorias_acreditaciones/en_def/adjuntos/6757_Izenpe_Browser_Attestation_2017.pdf

Audit Statement Date: 2017-07-25
BR Audit: 
http://www.izenpe.eus/contenidos/informacion/auditorias_acreditaciones/en_def/adjuntos/6757_Izenpe_Browser_Attestation_2017.pdf

BR Audit Statement Date: 2017-07-25
EV Audit: 
http://www.izenpe.eus/contenidos/informacion/auditorias_acreditaciones/en_def/adjuntos/6757_Izenpe_Browser_Attestation_2017.pdf

EV Audit Statement Date: 2017-07-25
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   NetLock Arany (Class Gold) Főtanúsítvány
Standard Audit: 
http://www.netlock.hu/docs/dokumentumok/Certificate%20ETSI%20ENG.pdf

Audit Statement Date: 2017-10-05
BR Audit: 
http://www.netlock.hu/docs/dokumentumok/Certificate%20ETSI%20ENG.pdf

BR Audit Statement Date: 2017-10-05
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   OpenTrust Root CA G1
   OpenTrust Root CA G2
   Certplus Root CA G1
   Class 2 Primary CA
   OpenTrust Root CA G3
   Certplus Root CA G2
Standard Audit: 
https://bug1297034.bmoattachments.org/attachment.cgi?id=8916590

Audit Statement Date: 2017-07-24
BR Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8916590
BR Audit Statement Date: 2017-07-24
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SECOM Trust.net - Security Communication RootCA1
   Security Communication RootCA2
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221101

Audit Statement Date: 2017-08-31
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221098

BR Audit Statement Date: 2017-08-31
EV Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221100

EV Audit Statement Date: 2017-08-31
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Visa eCommerce Root**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: http://enroll.visaca.com/WTCA%20eComm.pdf
Audit Statement Date: 2017-07-26
BR Audit: http://enroll.visaca.com/WTBR%20eComm.pdf
BR Audit Statement Date: 2017-07-26
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SSL.com EV Root Certification Authority ECC**
   SSL.com Root Certification Authority ECC**
   SSL.com Root Certification Authority RSA**
   SSL.com EV Root Certification Authority RSA R2**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: