Closed Bug 409236 Opened 17 years ago Closed 15 years ago

Add GeoTrust's ECC root

Categories

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

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jschiavo, Assigned: kwilson)

References

Details

Attachments

(4 files)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Build Identifier: 

Please accept the attached GeoTrust root certificate for inclusion in Firefox. 

This CA will be used to sign certificates for SSL-enabled servers, and may
in the future be used to sign certificates for digitally-signed executable code
objects.

Name of the CA certificate is GeoTrust Primary Certificate
Authority - G2

Link to GeoTrust's CPS - http://www.geotrust.com/resources/repository/legal.asp

Attestation of our conformance to the stated verification requirements can be
found here: https://cert.webtrust.org/ViewSeal?id=650

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Attached file GeoTrust root CA
The attached files contains a new Root CA from GeoTrust for inclusion in FireFox
Please note that certificates go into Mozilla's NSS database, which is used by a number of Mozilla products and such derived products as SeaMonkey.  A reference to Firefox is incorrect.  I'll leave this to Hecker to correct the Summary.  
Summary: Request for inclusion of GeoTrust's ECC root in FireFox's default root store → Add GeoTrust's ECC root
The attached email is from KPMG stating that our annual WebTrust for CAs reports for the VeriSign, Thawte and GeoTrust brands (most recently covering the period ending November 30, 2007) cover the effectiveness of CA controls including the CA key generation process based on the WebTrust for CAs criteria.
Here is the link to our updated CPS which includes our ECC root:

http://www.geotrust.com/resources/cps/pdfs/GeoTrustCPS-Version1.1.pdf

See Section 5.6. "GeoTrust Primary Certification Authority – G3: Expires December 1, 2037" was added
Accepting this bug and putting it into the queue with the other CA requests. At present I cannot say for certain exactly when we will be able to process this.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I have set up a public-facing web server with this root and an SSL cert signed by it (also with an ECC key). The url is https://ecc-test-valid.geotrust.com. I'm not sure if the name is in DNS yet, so you can also hit it at https://205.180.234.253.
FYI, If I add the following entries to my etc/hosts file:

205.180.234.250 ecc-test-valid.verisign.com
205.180.234.252 ecc-test-valid.thawte.com
205.180.234.253 ecc-test-valid.geotrust.com

and then download and import the root CA cert which is attached to this bug 
into my cert DB and mark it trusted for SSL, and then visit the test URL 
given above in this bug (https://ecc-test-valid... ),
it works for me.  :)

If I view the server and root CA certs in the cert viewer (by click on the 
browser's lock icon in the lower right hand corner of the window chrome),
the browser has no trouble displaying them.
Reassigning to Kathleen Wilson to do information gathering.
Assignee: hecker → kathleen95014
Status: ASSIGNED → NEW
I have been asked to do the information gathering and verification for this request as per http://wiki.mozilla.org/CA:Information_checklist.  The attached document provides a summary of the information that has been gathered and verified so far. I have the following questions and request for further information:

1) Can you provide a public URL to the CRL for this root?

2) If applicable, please provide OCSP responder URL. (I don’t think this is applicable)

3) The requested Trust Bits for this root are Websites (SSL/TLS) and Code Signing.  Not email.  Correct?

4) Please provide a certificate hierarchy diagram and/or description for the sub-CA’s (current or planned) for this root.

a) List or description of subordinate CAs operated by the CA organization associated with the root CA. (For example, this might include subordinate CAs created to issue different classes or types of end entity certificates: Class 1 vs. class 2 certificates, qualified vs. non-qualified certificates, SSL certificates vs. email certificates, and so on.)
For internally-operated subordinate CAs the key is to confirm that their operation is addressed by the relevant CPS, and that any audit covers them as well as the root.

b) For subordinate CAs operated by third parties, if any: 
General description of the types of third-party subordinates that exist, and what the general legal/technical arrangements are by which those subordinates are authorized, controlled, and audited.
(For example, contractual arrangements should require third-party subordinates to operate in accordance with some CPS/CP. Technical arrangements might include name constraints, not allowing them to create their own subordinates, etc.) 

c) List any other root CAs that have issued cross-signing certificates for this root CA


Thanks,
Kathleen
1) Can you provide a public URL to the CRL for this root?
Not at this time, since we do not actively issue certificates from this root. We're trying to get this root in Firefox in anticipation of a market in the near future.

2) If applicable, please provide OCSP responder URL. (I don’t think this is
applicable)
This is not applicable since this is a root certificate. We will provide OCSP Responder URLs for certificates signed by this root.

3) The requested Trust Bits for this root are Websites (SSL/TLS) and Code
Signing.  Not email.  Correct?
Correct.
4) Please provide a certificate hierarchy diagram and/or description for the
sub-CA’s (current or planned) for this root.

a) List or description of subordinate CAs operated by the CA organization
associated with the root CA. (For example, this might include subordinate CAs
created to issue different classes or types of end entity certificates: Class 1
vs. class 2 certificates, qualified vs. non-qualified certificates, SSL
certificates vs. email certificates, and so on.)
For internally-operated subordinate CAs the key is to confirm that their
operation is addressed by the relevant CPS, and that any audit covers them as
well as the root.
Planned sub-CAs:
  Class 3 Secure Server CA (standard SSL certificates)
  Class 3 Secure Intranet Server CA (intranet SSL certificates)
  Class 3 Extended Validation SSL CA (EV SSL certificates)
  Class 3 Code Signing (EV and non-EV Code Signing certificates)
  OnSite Administrator CA - Class 3 (Enterprise portal Admin certificates)
  Class 3 Open Financial Exchange CA - G2 (OFX SSL certificates)
  Time Stamping Authority CA (time stamping certificates)
  Class 3 Mobile CA (authentication of servers in the mobile space)
  Class 3 WLAN CA (for Microsoft RADIUS/IAS servers)
  Class 3 Organizational CA (S/MIME certs for organizations)

b) For subordinate CAs operated by third parties, if any: 
General description of the types of third-party subordinates that exist, and
what the general legal/technical arrangements are by which those subordinates
are authorized, controlled, and audited.
(For example, contractual arrangements should require third-party subordinates
to operate in accordance with some CPS/CP. Technical arrangements might include
name constraints, not allowing them to create their own subordinates, etc.) 
This is n/a for this root.

c) List any other root CAs that have issued cross-signing certificates for this
root CA
This is n/a for this root.
The information gathering phase of this request is complete. Assigning bug to
Frank so he can proceed with the next phase.

I will update the pending list to include this root. There will be a slight
delay before the changes are visible.

Thanks,
Kathleen
Assignee: kathleen95014 → hecker
Status: NEW → ASSIGNED
Whiteboard: Information confirmed complete
Re-assigning this bug to Kathleen Wilson, since she'll be the person actively working on it.
Assignee: hecker → kathleen95014
I am now opening the first public discussion period for two requests from GeoTrust:

Bugzilla ID #409236 -- Add GeoTrust's ECC root and enable all three trust bits.

Bugzilla ID #484899 -- Add GeoTrust's SHA2 root and enable all three trust bits.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org 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

The discussion thread is called “GeoTrust Root Inclusion Request”

Please actively review, respond, and contribute to the discussion.
Whiteboard: Information confirmed complete → In public discussion
The public comment period for this request is now over. 

This request has been evaluated as per sections 1, 5 and 15 of the official CA policy at

 http://www.mozilla.org/projects/security/certs/policy/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request to add the “GeoTrust Primary Certificate Authority - G2” root certificate to NSS and enable all three trust bits.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by GeoTrust, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy]. GeoTrust appears to provide a service relevant to Mozilla users:  It is a commercial CA with worldwide operations. GeoTrust is a subsidiary of VeriSign.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list; the main document of interest is the CPS, which is provided in English.

http://www.geotrust.com/resources/cps/pdfs/GeoTrustCPS-Version1.1.1.pdf

Section 7 [Validation]. GeoTrust appears to meet the minimum requirements for subscriber verification, as follows:

* Email: Section 3.2.4 of GeoTrust’s CPS states that GeoTrust requires the certificate applicant to prove control over the Contact Address, which is the email address to be included in the cert. GeoTrust’s process for proving control over the email address is to send an email to the Contact Address requiring the applicant to respond to a link 
and enter a PIN that is also sent via email.

* SSL:  Domain Name Verification is described in Section 3.2.3 of GeoTrust’s CPS. GeoTrust uses an automated system to check the whois db to verify ownership/control of the domain name.  When GeoTrust can't automatically parse the whois data and needs to manually verify via the web and the generic options available won't work, GeoTrust allows the customer to enroll with a domain approver email of supp...@geotrust.com. These orders then go into a queue for GeoTrust’s support team to manually contact the applicant and request the domain approver email they want to use. The email the applicant requests must still be one of the whois contacts or generic options. GeoTrust’s support team will manually vet the requested email to ensure it meets their guidelines (by doing a web based whois lookup or verifying the email matches one of the generic options). 
** When the SSL cert contains an IP address in the CommonName field. GeoTrust Verifies the Organization’s ownership of the IP address.

* Code: Section 3.2.2 of GeoTrust’s CPS describes the steps taken to verify the identity of the certificate subscriber.

Section 8-10 [Audit]. Section 8-10 [Audit]. GeoTrust’s audits have been performed within the past year by KPMG, and the audit reports are posted on cert.webtrust.org.  The WebTrust CA audit report covers this root. No issues were noted in the audit report.

Section 13 [Certificate Hierarchy]. GeoTrust’s roots sign intermediate CAs, which sign end-entity certificates. GeoTrust’s CA hierarchy diagram:
https://bugzilla.mozilla.org/attachment.cgi?id=400117

Other: 
* CRL: According to section 4.9.7 of GeoTrust’s CPS, GeoTrust shall post the CRL online at least weekly (but no later than twenty-four (24) hours after revocation of a Certificate).
** GeoTrust is not yet actively issuing certs from this root, so no CRL exists yet.
* OCSP: not provided 

There are three Action Items that resulted from the discussion. These will be tracked separately in bug #484899, and approval/inclusion may proceed in parallel.

ACTION: GeoTrust will remove the following email addresses from their list of options for domain validated certs: is, it, mis, ssladministrator, sslwebmaster. GeoTrust has committed to notifying their customers according to their 6-month SLAs, and then complete the changes in the February/March 2010 timeframe.

ACTION: GeoTrust will update their list to meet the CAB/Forum guidelines of acceptable email addresses for domain validated certs, when the CAB/Forum guidelines are provided.

ACTION: GeoTrust will update their CPS to clarify the domain verification procedures as per this discussion. Note that the clarification is not significant enough to warrant requiring another audit, and the changes will be covered in their annual audit.

Based on this assessment I recommend that Mozilla approve this request to add the “GeoTrust Primary Certificate Authority - G2” root certificate to NSS and enable all three trust bits.
Kathleen, since you're officially peer now for CA inclusion decisions I'm happy to let you do the formal approval for this and future requests.
To the representatives of GeoTrust: Thank you for your cooperation and your patience.

To all others who have commented on this bug or participated in the public discussion: Thank you for volunteering your time to assist in reviewing this CA request.

As per the summary and recommendation in Comment #16, and on behalf of the Mozilla project I approve this request from GeoTrust to include the following root certificate in Mozilla, with trust bits set as indicated:

* GeoTrust Primary Certificate Authority - G2 (web sites, email, code signing)

I will file the NSS bug to effect the approved changes.
Whiteboard: In public discussion → Approved
Depends on: 517242
I have filed bug #517242 against NSS for the actual changes.
Whiteboard: Approved → Approved - awaiting NSS
Confirmed that this root is a Builtin Object Token in Firefox 3.6.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: Approved - awaiting NSS
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: