484899 - Add GeoTrust's SHA2 root

Status: RESOLVED FIXED

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

Description

[Jay Schiavo]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
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

Comment 1

[Jay Schiavo]

Correction on the request, should read please add root to Mozilla's NSS database

Comment 2

[Jay Schiavo]

Attachment: GeoTrust's SHA256 root CA

Attached is GeoTrust's SHA256 root for inclusion in Mozilla's NSS database.

Comment 3

[Jay Schiavo]

Name of the root is GeoTrust Primary Certification Authority – G3, not GeoTrust Primary Certificate Authority - G2 as stated earlier.

Comment 4

[Kathleen Wilson]

Accepting this bug.

I will begin the Information Gathering and Verification phase soon as described in https://wiki.mozilla.org/CA:How_to_apply

In the meantime, please provide the information listed in
https://wiki.mozilla.org/CA:Information_checklist

Comment 5

[Kathleen Wilson]

Hi Jay,

There is another GeoTrust request in the queue for public discussion at
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
http://www.mozilla.org/projects/security/certs/pending/#GeoTrust
http://bugzilla.mozilla.org/show_bug.cgi?id=409236

Does it make sense to combine these two requests into one public discussion?  Or are they sufficiently different that they should be discussed separately?

For this request, please provide the information for this root as was provided for the other root in the Information Gathering Document. Note that the potentially problematic practices list has grown, so please review the new list at http://wiki.mozilla.org/CA:Problematic_Practices

Thanks,
Kathleen

Comment 6

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

Attaching the initial information gathering document, which summarizes the data from both this request and from bug 409236.  The same CP/CPS and audit cover both roots, so it’ll be more efficient to have one public discussion which covers both requests.

There is quite a bit of information that is still needed for this root.  Please review the attached document and respond to the items that are highlighted in yellow.

Please also review the updated potentially problematic practices
http://wiki.mozilla.org/CA:Problematic_Practices
to indicate which of them are relevant for each root, and provide more information when relevant.

Comment 7

[Jay Schiavo]

Here is some additional information for this request based on questions in the information gathering document:

Webtrust audit report for 2008 updated at https://cert.webtrust.org/SealFile?seal=650&file=pdf. This includes our audit for EV.

CRL for EE certs was requested: We haven't issued any certificates from this Root so it has yet to issue a CRL.

OCSP is not provided under this root.

We have not used this root to issue any certificates to date, so there is not intermediate CA and this root is not cross signed.

Comment 8

[Jay Schiavo]

Verisign was asked to provide a description of this root and the CA hierarchy: This root CA has not yet issued any intermediate or subordinate CA certificates.  It may be used to issue Subordinate CA certificates for SSL. It will also be used to sign CRLs.

Verisign was asked if this Root Certificate Authority root CA
has any subordinate CAs that are operated by external third parties? - The
answer is no.

Verisign was asked if this root has been involved in cross-signing with another
root? - The answer is no.

Comment 9

[Jay Schiavo]

Verisign was asked which trust bits we are requesting for this root - We are requesting Websites (SSL/TLS) and Email (SMIME).

Verisign was asked if we were requesting this root for EV - the answer is yes.

Under problematic practices:

GeoTrust issues DV certs up to 5 years.
GeoTrust does not delegate any piece of the validation process to third parties. That is all done by us.
GeoTrust does not allow external entities to operate unconstrained sub CAs off any of our roots.
GeoTrust does not use OCSP responses signed by a certificate under a different root.
GeoTrust's CRLs do not have any extensions.

Comment 10

[Kathleen Wilson]

Thank you for the information. 

> Webtrust audit report for 2008 updated at
> https://cert.webtrust.org/SealFile?seal=650&file=pdf. This includes our 
> audit for EV.

This seal file contains two audit reports, one for WebTrust for CA and one for WebTrust for EV.

Both the GeoTrust Primary Certificate Authority - G2 and the GeoTrust Primary Certification Authority - G3 roots are covered by the WebTrust for CA audit report.

It is not clear that either of these roots are covered in the WebTrust EV audit. There at least needs to be a WebTrust EV Readiness audit for roots that are to be EV-enabled.

> Verisign was asked to provide a description of this root and the CA hierarchy:
> This root CA has not yet issued any intermediate or subordinate CA
> certificates.  It may be used to issue Subordinate CA certificates for SSL. It
> will also be used to sign CRLs.

Please describe the planned hierarchy for the G3 root, as you did for the G2 root.

> Verisign was asked if we were requesting this root for EV - the answer is yes.

Are you also requesting EV-enablement for the G2 root? 

For a root to be enabled for EV, a website (may be a test site) must be provided in which the EV-SLL cert chains up to the root.

> Under problematic practices:
> GeoTrust issues DV certs up to 5 years.

Is that the plan for SSL certs issued under these two roots?  

Will there be certs issued under either of these roots in which the identity/organization of the subscriber is not verified? Eg where only the domain name control is verified, but the identity/organization is not verified?

> We have not used this root to issue any certificates to date, so there is not 
> intermediate CA and this root is not cross signed.

Based on the CPS, it would appear that if either the G2 or G3 root were to provide EV, that an EV sub-CA would be created  which  is cross-signed by the off-line GeoTrust EV SSL CA root. The text is copied below.  Please explain if my interpretation is not correct:

CPS Appendix A1, section 7.d:
There are two GeoTrust EV Root certificates.
1 – The off-line GeoTrust Extended Validation SSL CA will be signed by the Equifax Secure Certification Authority Root certificate. This Root CA does not contain the certificatePolicies or extendedKeyUsage fields.
2 – The On-line Extended Validation SSL CA certificate is signed by the EV off-line Subordinate CA, And it is also signed by the GeoTrust Primary Certificate Authority. The EVOffline subordinate CA and the GeoTrust EV Root CA both have the same subject DN and use the same key


> We are requesting Websites (SSL/TLS) and Email (SMIME).
 
In order to enable the email trust bit, there must be text in the CP/CPS or other audited document that meets section 7 of the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/). The requirement is as follows:
“for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf; ”

Please point me to the text that demonstrates how GeoTrust verifies the ownership/control of the email address contained in the certificates that will be used for S/MIME.

Comment 11

[Jay Schiavo]

>>Please describe the planned hierarchy for the G3 root, as you did for the G2
root.

This root CA has not yet issued any intermediate or subordinate CA certificates.  It may be used to issue Subordinate CA certificates for SSL. It
will also be used to sign CRLs.

>>Are you also requesting EV-enablement for the G2 root? For a root to be enabled for EV, a website (may be a test site) must be provided in which the EV-SLL cert chains up to the root.

Yes, we would like this root EV enabled, but have not issued any certs off this root and do not have any EV enabled sites issued from this root.

>>Is that the plan for SSL certs issued under these two roots? Will there be certs issued under either of these roots in which the identity/organization of the subscriber is not verified? Eg where only the domain name control is verified, but the identity/organization is not verified?

We do plan to issue domain validated certs from the GeoTrust Primary Certificate
Authority - G2 roots, but have not decided with the GeoTrust Primary Certificate
Authority - G3 root. For validty period, we plan to issue per the new minimum SSL guidelines being developed by the CAB Forum. 

Your interpretation is correct of our plans to create a new EV subca and cross-certify. 

Section 3.2.4 of the CPS describes authentication for control of the email address.

Comment 12

[Eddy Nigg (StartCom)]

@Kathleen: The proposed validity of the minimal guidelines Jay refers to is 27 month, the same like EV.

Comment 13

[Kathleen Wilson]

Thanks for the clarifications.

>> Please describe the planned hierarchy for the G3 root, as you did 
>> for the G2 root.
> This root CA has not yet issued any intermediate or subordinate CA
> certificates.  It may be used to issue Subordinate CA certificates 
> for SSL. It will also be used to sign CRLs.

So is the following a correct interpretation of your statement?
--
Planned sub-CAs for the G3 root:
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)
--
If this is a correct interpretation of your statement, then you only need the Websites trust bit enabled for this root, correct? Eg you don’t need the Email trust bit enabled for this root?

> Yes, we would like this root EV enabled, but have not issued any certs 
> off this root and do not have any EV enabled sites issued from this root.

For each root that you want to enable for EV, a test site needs to be provided that has an EV-SSL cert chaining up to the root.

Anyways, to enable EV for a root, there needs to be at least a WebTrust EV Readiness audit performed on the root. It is not clear that either of these roots is covered in the WebTrust EV audit. 

Has there been a WebTrust EV Readiness audit on these roots?  If not, shall we postpone the request for EV enablement for both of these roots?

> Section 3.2.4 of the CPS describes authentication for control of the 
> email address.

Am I looking at the correct version of the CPS?
http://www.geotrust.com/resources/cps/pdfs/GeoTrustCPS-Version1.1.1.pdf

In the first section numbered 3.2.4 (there are two with the same number), and titled “Authentication of individual identity” it says:  “All Applicants are required to include an e-mail contact address (“Contact Address”) and telephone number (“Telephone Number”) within the My Credential enrollment application and prove control over the Contact Address and Telephone Number as specified below.”

Please let me know which page number has the information that is “specified below”.

Comment 14

[Jay Schiavo]

here is a URL with a test cert issued via GeoTrust's G2 SHA256 root - https://ptnr-geotrust256.bbtest.net

We do not currently use this root for production level certificates, so this certificate was issued directly from the root. In production our plan will be to use this root to sign an intermediate CA that will issue the ee certs.

Comment 15

[Jay Schiavo]

- We would like both the G2 and G3 roots enabled for Websites trust bit and Email trust bit.

- The CPS at https://www.geotrust.com/resources/cps/pdfs/GeoTrustCPS-Version1.1.1.pdf is the correct version.

- 'as specified below' is referring to section 4.1 and it's subsections.

- GeoTrust did complete an EV readiness audit back in 2006 to be eligible to issue EV certificates. At that time the G2 root was not created so was not included in the EV readiness audit. Per the letter from KPMG (our auditor) attached to bugzilla 409236, our annual WebTrust for CAs reports for the GeoTrust cover the effectiveness of CA controls including the CA key generation process based on the WebTrust for CAs criteria.  Each audit cycle, KPMG tests various CA key generation ceremonies and identify specific production CAs in their reports.

- we do not have EV test certs for the G2 root as we do not have this root enabled in a production environment yet.

Comment 16

[Kathleen Wilson]

>>> Section 3.2.4 of the CPS describes authentication for control of the 
>>> email address.
>> In the first section numbered 3.2.4 (there are two with the same number), and
>> titled “Authentication of individual identity” it says:  “All Applicants are
>> required to include an e-mail contact address (“Contact Address”) and 
>> telephone number (“Telephone Number”) within the My Credential enrollment 
>> application and prove control over the Contact Address and Telephone Number 
>> as specified below.”
>> Please let me know which page number has the information that is “specified
>> below”.
> - 'as specified below' is referring to section 4.1 and it's subsections.

I have read through section 4.1, and it is still not clear to me how GeoTrust verifies that the certificate applicant has ownership/control of the email address to be included in the certificate. Please clarify.


> - GeoTrust did complete an EV readiness audit back in 2006 to be eligible to
> issue EV certificates. At that time the G2 root was not created so was not
> included in the EV readiness audit. Per the letter from KPMG (our auditor)
> attached to bugzilla 409236, our annual WebTrust for CAs reports for the
> GeoTrust cover the effectiveness of CA controls including the CA key 
> generation process based on the WebTrust for CAs criteria.  Each audit cycle, 
> KPMG tests various CA key generation ceremonies and identify specific 
> production CAs in their reports.

I am not questioning the WebTrust for CA audit -- both the GeoTrust Primary Certificate Authority - G2 and the GeoTrust Primary Certification Authority - G3 roots are covered by the WebTrust for CA audit report.

My question is in regards to EV-enablement of either of these roots. One of the very minimum requirements for EV-enabling a root is that a WebTrust EV Readiness audit has been preformed on the root.  It appears that neither of these roots have been part of a WebTrust EV Readiness audit, so my recommendation is to not request EV-enablement at this time. 

I recommend that we proceed with the root inclusion request now, and that you file a new bug requesting EV-enablement when a WebTrust EV Readiness audit has been successfully completed on these roots.

Comment 17

[Jay Schiavo]

Our process for client certs is we send an email to the address applying for the cert and require them to respond to a link and enter a PIN we sent them.

For the SHA256 root, that is fine for now and we can apply to EV enable that root at a later date.

Comment 18

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Jay, please review this version of the Information Gathering document for
accuracy and completeness.

Comment 19

[Jay Schiavo]

Here are our additional comments:

- We would like both the G2 and G3 to be enabled for all trust bits

- PAGE 2-7: Off the G2-G3 GeoTrust roots, both have a huge list of subordinates. What are all those subs? They all look Verisign names? Are those typos? We currently do not have any sub CAs off either of these roots at this time.

PAGE 2-7: There was some confusion in our agreeing to your description of the current cross signing strategy with GeoTrust Primary Certificate Authority(not G2-G3). The Equifax Secure Certificate Authority signs the GeoTrust Primary Certificate Authority Cross cert not the GT Extended Validation CA. 

- We do plan to request EV enablement of these roots, but will do that in a separate bug. The question we have is what are you looking for regarding an EV readiness audit on a root CA? Would it be that it was properly witnessed during creation and meets the criteria in the EV guidelines?

Comment 20

[Kathleen Wilson]

The only information I now have about the planned hierarchy for these roots is:
“We currently do not have any sub CAs off either of these roots at this time.”
And for the G3 root: 
“This root CA has not yet issued any intermediate or subordinate CA certificates.  It may be used to issue subordinate CA certificates for SSL. It will also be used to sign CRLs.”

Yet, you are asking to enable all three trust bits:  SSL, Email, and Code Signing.

Can you provide more information about the planned hierarchy and usage of each of these roots to explain why you need all 3 trust bits enabled?

> PAGE 2-7: There was some confusion in our agreeing to your description of the
> current cross signing strategy with GeoTrust Primary Certificate Authority(not
> G2-G3). The Equifax Secure Certificate Authority signs the GeoTrust Primary
> Certificate Authority Cross cert not the GT Extended Validation CA.

I copied that cross-signing text directly from CPS Appendix A1, section 7.d. Are you saying that the text doesn’t apply to these two roots? So will these roots ever be involved in cross-signing, for EV or other?

> The question we have is what are you looking for regarding an EV
> readiness audit on a root CA? 

I believe that a WebTrust for EV Readiness audit will check that your root, EV sub-CA, and end-entity issuance follow the WebTrust for EV criteria. I believe that other CAs who have done the WebTrust for EV Readiness audit have issued test certs for this purpose.

Comment 21

[Jay Schiavo]

> Can you provide more information about the planned hierarchy and usage of each
> of these roots to explain why you need all 3 trust bits enabled?

Verisign: our plan is to create intermediate sub CAs that chain up to this root. We would then issue digital certificates from these sub CAs for securing web servers, SMIME and Code signing. We are not currently using this root in production so have not created the sub CAs, but our plan is to move all certificate issue to be by online subCAs chaining up to offline root CAs.

> So will these roots ever be involved in cross-signing, for EV or other?

Verisign: These roots may be involved in cross-signing for EV or other. We have not decided on the implementation details at this point. I will submit a separate bug related to EV enabling these roots.

Comment 22

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 23

[Kathleen Wilson]

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

The discussion thread is called “GeoTrust Root Inclusion Request”

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

Comment 24

[Kathleen Wilson]

Attachment: Planned CA Hierarchy

Comment 25

[Kathleen Wilson]

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 Certification Authority - G3” 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 [e-mail]. 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 this bug, 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 Certification Authority - G3” root certificate to NSS and enable all three trust bits.

Comment 26

[Frank Hecker]

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.

Comment 27

[Kathleen Wilson]

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 #25, 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 Certification Authority - G3 (web sites, email, code signing)

I will file the NSS bug to effect the approved changes.

Comment 28

[Kathleen Wilson]

I have filed bug #517234 against NSS for the actual changes.

Comment 29

[Kathleen Wilson]

Calling out the remaining action items, so this bug doesn't get closed until the action items have also completed.

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.

GeoTrust, please post updates on the progress of these action items here, in this bug.

Comment 30

[Kathleen Wilson]

I have confirmed that this root is now a Builtin Object Token in Firefox 3.6. However, this bug will remain open until GeoTrust has completed their action item as per Comment #29.

Jay, Please update this bug when GeoTrust has completed the action item.

Comment 31

[David E. Ross]

I would suggest that Kathleen establish a reasonable deadline by which GeoTrust must respond to the action items in Comment #29.  If GeoTrust fails to respond by that date, the appropriate action would be to turn off all trust bits in the root for the next update (security, stability, or major) of any product containing the root.  

Actually, this should be done on all requests to install roots when there are open action items if the roots are already installed in products for which end-user delivery is pending or has already occurred.

Comment 32

[Jay Schiavo]

Hi Kathleen,

Here is an update on the action items for GeoTrust from this bug:

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.

VeriSign: the release containing the updates to remove these options is scheduled for deployment on February 25th. 

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.

VeriSign: The CAB/Forum SSL minimum guidelines are still under discussions at this time. 

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.

VeriSign: this was completed back in November and a new version of the CPS was posted.

Comment 33

[Kathleen Wilson]

Jay, Thank you for posting the updates on VeriSign's action items.

All, The updated CPS as per the third action item is posted:
 http://www.geotrust.com/resources/cps/pdfs/GeoTrustCPS-Version1.1.2.pdf
The section of interest is 3.2.3, Authentication of Domain Name
I have confirmed that the clarifications have been added.

Comment 34

[Kathleen Wilson]

Tony, do you have an update on the first action item in Comment #32?

Comment 35

[Tony Berman]

(In reply to comment #13)
> Thanks for the clarifications.
> >> Please describe the planned hierarchy for the G3 root, as you did 
> >> for the G2 root.
> > This root CA has not yet issued any intermediate or subordinate CA
> > certificates.  It may be used to issue Subordinate CA certificates 
> > for SSL. It will also be used to sign CRLs.
> So is the following a correct interpretation of your statement?
> --
> Planned sub-CAs for the G3 root:
> 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)
> --
> If this is a correct interpretation of your statement, then you only need the
> Websites trust bit enabled for this root, correct? Eg you don’t need the Email
> trust bit enabled for this root?
> > Yes, we would like this root EV enabled, but have not issued any certs 
> > off this root and do not have any EV enabled sites issued from this root.
> For each root that you want to enable for EV, a test site needs to be provided
> that has an EV-SSL cert chaining up to the root.
> Anyways, to enable EV for a root, there needs to be at least a WebTrust EV
> Readiness audit performed on the root. It is not clear that either of these
> roots is covered in the WebTrust EV audit. 
> Has there been a WebTrust EV Readiness audit on these roots?  If not, shall we
> postpone the request for EV enablement for both of these roots?
> > Section 3.2.4 of the CPS describes authentication for control of the 
> > email address.
> Am I looking at the correct version of the CPS?
> http://www.geotrust.com/resources/cps/pdfs/GeoTrustCPS-Version1.1.1.pdf
> In the first section numbered 3.2.4 (there are two with the same number), and
> titled “Authentication of individual identity” it says:  “All Applicants are
> required to include an e-mail contact address (“Contact Address”) and telephone
> number (“Telephone Number”) within the My Credential enrollment application and
> prove control over the Contact Address and Telephone Number as specified
> below.”
> Please let me know which page number has the information that is “specified
> below”.

(In reply to comment #32)
> Hi Kathleen,
> Here is an update on the action items for GeoTrust from this bug:
> 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.
> VeriSign: the release containing the updates to remove these options is
> scheduled for deployment on February 25th. 
> 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.
> VeriSign: The CAB/Forum SSL minimum guidelines are still under discussions at
> this time. 
VeriSign: as of 3/3/2010 these aliases were removed for GeoTrust Domain validated certificates.
> 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.
> VeriSign: this was completed back in November and a new version of the CPS was
> posted.

Comment 36

[Kathleen Wilson]

As per Comment #32, there were three actions that were being tracked:

1) 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.

VeriSign completed this action item on 3/3/2010.

2) 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.

This action item will be required for all affected CAs once the CA/B Forum  updates their guidelines.  I don't think I need to track this item in this bug.

3) 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.

This action was completed as per Comment #33.

Therefore, I am closing this bug, noting that the action items have been sufficiently addressed.