430694 - Enable GTE CyberTrust Global Root for EV Extended Validation SSL

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Root Program, task)

Description

[Steven Medin]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; MCI Windows Corporate Image; .NET CLR 1.1.4322; .NET CLR 2.0.50727; MCI Windows Corporate Image; MCI Windows Corporate Image)
Build Identifier: 

The following report uses a format requested by Gerv Markham in the CA/Browser Forum.  In this report, we kindly request that the GTE CyberTrust Global Root be enabled with Extended Validation SSL support.

CA Details
----------

CA Name: Verizon Business, a division of Verizon Communications.  (Formerly known as Cybertrust, Betrusted, Baltimore Technologies and GTE CyberTrust)
Website: http://www.verizonbusiness.com/us/security/identity, http://cybertrust.omniroot.com/repository 
One Paragraph Summary of CA:
Verizon Business Security Solutions Powered by Cybertrust operates a commercial certificate authority service for businesses and governments internationally.  Our CA services represent the experience of an organization which has been issuing trusted certificates since 1996.  In addition to our public trust services, we operate rigorously audited national identity card programs and government agency programs that dwarf the total annual issuance of SSL certificates by orders of magnitude.
Audit Type (WebTrust, ETSI etc.): WebTrust
Auditor: Ernst and Young
Auditor Website: www.ey.com/be
Audit Document URL(s): https://cert.webtrust.org/SealFile?seal=676&file=pdf 
URL of certificate hierarchy diagram:  Not published.  Under our GTE CyberTrust Global Root, we directly operate the Cybertrust SureServer Standard Validation CA, Cybertrust Surecredential CA, Cybertrust SureCodesign CA, and a cross-certificate of the Cybertrust Global Root.  We subordinate to customer premise CAs for enterprise usage only and subject to annual internal audits, net worth requirements, and multimillion dollar general liability and errors and omissions insurance coverage.  We also subordinate to commercial reseller CAs required to pass WebTrust audits annually.  We require enterprise customers to operate an on-premise offline intermediate CA which we sign, and an operational issuing CA under it, creating a four-tier PKI hierarchy.

Certificate Details
-------------------

Certificate Name:  GTE CyberTrust Global Root
Summary Paragraph, including the following:
  - End entity certificate issuance policy,
    i.e. what you plan to do with the root Certificate HTTP URL (on CA website):
This root has been embedded in PKI enabled products since its creation in 1998.  This is presently our mainstream root, issuing our standard validation SSL server certificates, user authentication and secure email certificates, and code signing certificates.  
Version: 1
SHA1 Fingerprint: 97 81 79 50 d8 1c 96 70 cc 34 d8 09 cf 79 44 31 36 7e f4 74
Modulus Length (a.k.a. "key length"): 1024
Valid From (YYYY-MM-DD): 1998-08-12
Valid To (YYYY-MM-DD): 2018-08-13
CRL HTTP URL: http://www.public-trust.com/cgi-bin/CRL/2018/cdp.crl
CRL issuing frequency for end-entity certificates: every three hours with four day grace period for DR/BCP
OCSP URL: not applicable, we presently use CRL DP status checking but we operate a redundant CoreStreet environment and we are in early planning stages to leverage that environment.
Class (domain-validated, identity/organisationally-validated or EV): SureServer, SureCodesign and SureCredential Professional are organizationally validated and include telephone confirmation with named parties in the request.  SureCredential Personal does not contain an organization field in the distinguished name and is therefore only identity verified.  While our Extended Validation CA is signed under our Cybertrust Global Root, that root is cross-certified to this GTE CyberTrust Global Root for the purposes of legacy ubiquity.  Certain browser users who examine the certificate chain will see a four tier chain terminating in the GTE CyberTrust Global Root for certificates which have been issued according to the EV Guidelines.
Certificate Policy URL:  http://cybertrust.omniroot.com/repository
CPS URL: http://cybertrust.omniroot.com/repository
Requested Trust Indicators (email and/or SSL and/or code): email, SSL, code.
URL of website using certificate chained to this root (if applying for SSL): https://cybertrust.omniroot.com
EV CPS OID: 1.3.6.1.4.1.6334.1.100.1


Reproducible: Always

Comment 1

[Frank Hecker]

I'm assigning this bug to Kathleen Wilson, who'll be gathering information relating to this and other requests.

Comment 2

[Kathleen Wilson]

Hi Steve,

As per Frank’s note, I have been asked to gather and verify information for this request.  As such, I have the following questions.

1) This root is version 1 and is 1024 bit. As such, it’ll be superseded by Baltimore CybeTrust root. When do you expect this root to be completely phased out?  Why EV enable this root now?

2) Are you planning to enable OCSP for this root? Or are you waiting for
https://bugzilla.mozilla.org/show_bug.cgi?id=413997
to be fixed so this root can be EV-enabled without having OCSP?

3) Would you please confirm that the following is the accurate and complete list of internally-operated sub-CAs for this root?
Under GTE CyberTrust Global Root are:
•	Cybertrust SureServer Standard Validation CA
•	Cybertrust Surecredential CA
•	Cybertrust SureCodesign CA
•	Cybertrust SureServer EV CA -- relies on the Cybertrust Global Root's cross-certificate to the GTE CyberTrust Global Root for legacy browsers

4) In regards to sub-CAs operated by 3rd-parties, would you please confirm that the following is accurate:
There are sub-CAs operated by third parties, but no list provided due to confidentiality concerns.

The subordinates issued to customer premise CAs are for enterprise usage only and subject to annual internal audits, net worth requirements, and multimillion dollar general liability and errors and omissions insurance coverage. CyberTrust retains the right to make an enterprise customer conduct an external audit at their cost if they have reason to suspect compliance issues.

There are also subordinates issued to commercial reseller CAs who are required to pass WebTrust audits annually.  

The subordinate CAs inherit the CyberTrust CP and CPS and they are required to pass WebTrust against it in all but the oldest legacy cases where CyberTrust conducts their own audits onsite directly.

At most once per week the CyberTrust security team exposes the  root for
customer subordination.  CyberTrust strongly recommens that the
customers operate one tier offline and manage online issuing CAs under that.
CyberTrust supports them with path length constraint of 1 just for that purpose.


5) In regards to cross-signing, please confirm:
The Extended Validation CA is signed under Cybertrust Global Root, and that root is cross-certified to this GTE CyberTrust Global Root for the purposes of legacy ubiquity.  Certain browser users who examine the certificate chain will see a four tier chain terminating in the GTE CyberTrust Global Root for certificates which have been issued according to the EV Guidelines.


6) When do you expect to have the WebTrust EV audit done for this root?

7) One of the things I’m supposed to do is to check the CP/CPS to verify that the email account associated with the email address in the cert is owned by the subscriber, in addition to verification of subscriber’s legal identity.  I looked for the verification of email address ownership in the sections about Securecredentials, but I didn’t see it explicitly stated. Please point me to the appropriate text in the CP or CPS that address this.

Thanks,
Kathleen

Comment 3

[Kathleen Wilson]

Attachment: GTE CyberTrust Global Root cert

Adding root as exported from Firefox, to be used in pending list.

Comment 4

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 5

[Kathleen Wilson]

Assigning this bug back to Frank, as the information has been gathered and verified.

The items of note are:

1) The Cert version is 1, and the modulus length is 1024.
“There are still many mobile devices in APAC that cannot handle 2048-bit keys.  Current web server technology forces our customers to make a choice between EV and mobile support.  In the APAC market, the majority of SSL terminations are with a mobile device.  Without enabling EV on a 1024 bit root, we obstruct APAC market adoption of EV.  The JCAF has made similar comments in this regard in the CAB Forum discussion lists.”

2) The Extended Validation CA is signed under Cybertrust Global Root, and that root is cross-certified to this GTE CyberTrust Global Root for the purposes of legacy ubiquity.  Certain browser users who examine the certificate chain will see a four tier chain terminating in the GTE CyberTrust Global Root for certificates which have been issued according to the EV Guidelines.

3) There are sub-CAs operated by third parties, but no list provided due to confidentiality concerns. “Resellers are required to pass WebTrust.  We are in the process of moving our legacy resellers to WebTrust audit, these audits are currently in progress.
The number of sub-CAs operated at enterprise customers for their own use would be approximately 35.  We prefer path length zero to restrict further subordinates, but we accept a practice whereby the customer attests that they will only operate the intermediate tier in an offline manner.  We also always limit use to within arms length of the enterprise.

The number of resellers is 5.  Specific customer identification is
intellectual property which can be disclosed under NDA.  Resellers are allowed to issue subordinate CAs to create separate classes of certificate issuers, but are contractually blocked from establishing subordinates operated by any other organization, even if at reseller premises.  Several of these organizations are undergoing their first audits and/or point in time audits.”

Are any of the sub-CAs that are operated by third-parties are or will be EV enabled?
 If the answer is yes, then please refer to 
http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf
section 7.b.1 and section 37b.
”That is language that is very deeply understood and contemplated before we enabled our partner to issue EV SSL.  Had we not had such a long working relationship, we would not have taken the risk to assume responsibility for their warranties and the critical findings in their WT/EVCA audits.
I commit that we entirely understand our obligations and fully support the language in the Guidelines.  Our partner is obligated to perform exactly as we are, they are bound to the same CPS and audited against it.  By this equal treatment, we suggest that we can use one OID to denote the policy even though two parties perform under it.  It is clear through the differing subordinate CAs which party is responsible for issuance.
We further understand that this presents a risk if our partner fails to satisfy Foundation requirements and needs to be pulled from Firefox because using a single OID does not offer granularity to remove them but keep us. We suggest that in such a case we would revoke the partner's CA certificate.”

From Kathleen Wilson:
I have reviewed the information provided by Steven Medin, including one of the service description documents, and have confirmed the information below.
From Steven Medin:
“The attached service description document is bound by reference into the terms and conditions that form the master service agreement with any reseller that operates a subordinate CA at their premises that is chained to the GTE CyberTrust Global Root and its successors.  At section 2.3.5 find the stated requirement of WebTrust audit.  Our term Service Description does not imply marketing collateral, rather it details the legal specifics of a certain service while relying on the MSA for the typical legal language about the general business relationship.  It is a binding part of the MSA.

That service description is used for resellers that wish to issue SSL certificates which are NOT marked with EV SSL issuance ability.  It requires an initial and annual WT/CA audit.  It does not require an annual WT/EVCA audit because it does not grant EV issuance ability.

Before we will allow a reseller to issue EV SSL certificates, they must first have a completed WT/CA audit and a WT/EVCA point in time readiness check.  They must annually pass their WT/CA and WT/EVCA audits.  Their WT/EVCA audits become incorporated by reference into our WT/EVCA audit – we are directly responsible for resolution of their critical findings.

Because we expect very limited business relationships so strong that we will convey EV issuing privilege, we do not have prepackaged standard language defining the responsibilities of the parties in this case.  We currently have one reseller who has an EV-enabled subordinate CA.”

Comment 6

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

The attached document summarizes the information that has been gathered and verified for the following 3 CA inclusion requests.

Bugzilla ID: 430694
Bugzilla Summary: Enable GTE CyberTrust Global Root for EV Extended Validation SSL

Bugzilla ID: 430698
Bugzilla Summary: Enable Baltimore CyberTrust Root for EV Extended Validation SSL

Bugzilla ID: 430700
Bugzilla Summary: Add Cybertrust Global Root, plus enable EV SSL support

All three of these requests will be combined into one public discussion.

Comment 7

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 8

[Kathleen Wilson]

I am now opening the first public discussion period for this request from Verizon to enable EV the GTE CyberTrust Global Root certificate, which is already included in NSS.

I have started one discussion for all three of Verizon’s current requests: #430694, #430698, and #430700. 
It is called: “Verizon Root Inclusion and EV-enablement Request”

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding [e-mail] mailing list.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

Please actively review, respond, and contribute to the discussion.

Comment 9

[Kathleen Wilson]

The result of the public discussion of this request is that this root will not be enabled for EV.