430698 - Enable Baltimore CyberTrust 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 follows a format requested by Gerv Markham in the CA/Browser Forum.  In this report, we kindly request that the Baltimore CyberTrust Root be enabled for 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.  We presently have no subordinate CAs under the Baltimore CyberTrust Root at this time, but we will during the supported life of Firefox 3.

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

Certificate Name:  Baltimore CyberTrust 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 Firefox since version 1.0.  It is intended to be our mainstream root in the coming years as the GTE CyberTrust Global Root approaches the end of its useful life.  We presently have no subordinate CAs issued from this root.  We have issued test SSL server certificates directly from it for vendor testing.
Version: 3
SHA1 Fingerprint: d4 de 20 d0 5e 66 fc 53 fe 1a 50 88 2c 78 db 28 52 ca e4 74
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2000-05-12
Valid To (YYYY-MM-DD): 2025-05-12
CRL HTTP URL: http://www.public-trust.com/cgi-bin/CRL/202501/cdp.crl
CRL issuing frequency for end-entity certificates: presently not applicable, but will be 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): This root will issue the same brands and types of certificates as the GTE CyberTrust Global Root currently does once it supercedes the GTE root.  Those are: standard validation SSL server, personal identity user, personal and organizational identity user, and code signing certificates under our SureServer, SureCredential, and SureCodesign brands.  It will cross-certify our Cybertrust Global Root which we use exclusively for EV SSL issuance.  The cross-certification is to provide legacy user agent support once we retire the GTE root.
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): This root presently has no subordinate CAs issued and only limited directly issued SSL server certificates used in internal testing environments at this time.  The root is already embedded in Firefox.
EV CPS OID: 1.3.6.1.4.1.6334.1.200.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)  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?

2) Please confirm or correct: There are currently no internally or 3rd-party operated subordinate CAs issued from this root, and this root currently is not used in cross-signing. However, this root will supersede the GTE CyberTrust Global Root (bugzilla #430694) and as such will have the same sub-CAs and cross-signing that GTE CyberTrust Global Root has today.

3) Would you please provide a sample end-entity SSL cert issued via this CA?

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

Thanks,
Kathleen

Comment 3

[Kathleen Wilson]

Attachment: Baltimore CyberTrust Root cert

Attaching the Baltimore CyberTrust Root cert as exported from Firefox, for inclusion in the 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.

There are currently no subordinate CAs under the Baltimore CyberTrust Root, but there will be during the supported life of Firefox 3.  This root will issue the same sub-CA’s that are operated by 3rd-parties as the GTE CyberTrust Global Root currently does once it supersedes the GTE root (Bugzilla #430694).

As this root supersedes he GTE root, 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 and add the Code Signing trust bit for the Baltimore CyberTrust 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 first public comment period for this request is now over. Below is a summary of the action items that resulted from the discussion. 

Verizon has been requested to:

1) Issue the sub-CA that will have Code Signing certs, and issue a  test cert. Add information about their validation procedures for code signing applicants to their CPS, and subject that assertion to a WebTrust CA audit. 

2) Have a WebTrust CA audit and a WebTrust EV Readiness audit performed on this root. This, of course, will include creating the sub-CA that will issue EV-SSL certs, issuing a test EV-SSL cert, and having a point-in-time readiness audit 
for EV. 

3) We will also need a test website whose EV-SSL cert chains up to  this root. 

4) Provide evidence of the WebTrust audits that have been performed on the third-parties who will operate sub-CAs under this root. Since the names of the sub-CAs are considered confidential to Verizon, perhaps a third-party auditor can provide a statement that the WebTrust audits of the third-parties have been reviewed, and that the sub-CAs meet the requirements of section 7 of the Mozilla CA Certificate Policy? 

5) Test the OCSP responders of subCAs to make sure they work correctly in Firefox.

Please post updates to these action items in this bug.  When all of these items have been addressed, this request may move directly into the second public discussion.

Comment 10

[Steven Medin]

I believe that item 4 exceeds the requirements discussed prior to summarization.  We require WebTrust audits from any organization we subordinate that resells certificates to third parties to ensure prudent practice under a profit motive.  We request internal audits annually from our enterprise customers and only force an external audit when we suspect variance from our CPS.  In general, our enterprise subordinates face extreme cost obstacles that cause careful compliance to our requirements as a revocation from us can essentially shut down the infrastructure of their business.

We seek to provide the requested audits for the public resellers.  We seek exclusion for the enterprise internal use organizations.

Comment 11

[Kathleen Wilson]

Yes. That is consistent with what has been asked of other CAs. I apologize for not making that distinction.

Action Item #4 of Comment #9 only needs to be applied to the subCAs that resell certs to third parties.

Comment 12

[Kathleen Wilson]

Steven, Can this bug be closed? It's had no change since 2009.

Comment 13

[Ryan Sleevi]

Note that the requirements have changed since the first public discussion, according to the Mozilla Root Inclusion Policy.

According to http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html, Section 10, all sub-ordinate CA certificates MUST be technically constrained or publicly disclosed. 

As such, the procedures described in comment #10 would be insufficient now - contrary to the statement on comment #11 (under the old policy)

Comment 14

[Kathleen Wilson]

Please create a new bug if you would like to pursue this request again.