284677 - Add Go Daddy CA Cert to root store

Status: RESOLVED FIXED

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

Description

[Wayne Thayer (old account)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Please add two new Go Daddy root certificates to the Mozilla/Firefox root store.
 Here is the information requested when submitting new roots:

1.  the certificate data (or links to the data) for the CA certificate(s)
requested for inclusion - please email me and I will send the roots to you via a
secure channel and perform out of band verification
2.  for each CA certificate requested for inclusion, whether or not the CA
issues certificates for each of the following purposes within the CA hierarchy
associated with the CA certificate:
          o SSL-enabled servers,
          o digitally-signed and/or encrypted email, or
          o digitally-signed executable code objects - these two roots will be
used for all purposes including SSL, email, and code signing
3.  a Certificate Policy and Certification Practice Statement (or links to a CP
and CPS) or equivalent disclosure document(s) for the CA or CAs in question -
https://certificates.godaddy.com/repository (note that these new roots are not
yet posted on our repository page)
4.  information as to how the CA has fulfilled the requirements stated above
regarding its verification of certificate signing requests and its conformance
to a set of acceptable operational criteria- we are WebTrust certified.  We
perform domain ownership verification on all certificates issued.  

Reproducible: Always

Steps to Reproduce:
N/A

Actual Results:  
N/A

Expected Results:  
N/A

Comment 1

[Frank Hecker]

I'm accepting this bug and marking it as assigned to me. I have some additional
questions re the original information provided (number is the same as in the
original request).

1. Will the new root CA certs eventually end up being published on the
repository page along with the existing certs?

2. Will the new root CAs issue SSL, email, and object signing certs directly, or
will this be done through one or more subordinate CAs? (Incidentally note that
we include only true root certs in the default Mozilla list, not
intermediate/subordinate certs.)

3.a. The latest CP/CPS on your repository page is version 1.5, and refers to
"Starfield Root CAs" (currently the Valicert Class 2 CA) and "Starfield Issuing
CAs" (currently the Starfield Secure CA). Will the new roots basically be
considered "Starfield Root CAs" in the context of the CP/CPS, i.e., anything in
the current CP/CPS referring to "Starfield Root CAs" will apply to the new CAs
as well?

3.b. Will there be a new version 1.6 referencing the new root CAs in section
1.3.1? If so, do you plan to make any other substantive changes to the CP/CPS
for that version?

4.a. Re domain ownership validation of SSL certs, is the procedure used that
described in the answer to the FAQ "What is Domain Control Validation?", at the
following URL:

https://www.godaddy.com/gdshop/faq/faq.asp?se=%2B&app%5Fhdr=0&faq%5Fid=787&topic%5Fid=72&topic=SSL+Certificates

linked to from the TurboSSL product page and elsewhere?

4.b. Domain ownership validation as discussed in the FAQ strictly speaking
doesn't apply to email certs or object signing certs. Can you clarify what the
validation procedures are/will be for such certs? Are the links to more
information about this, similar to the link above for SSL certs? (I presume for
email certs you would validate ownership of the email account in a similar
manner to validating domain ownership, e.g., by sending verification emails to a
particular email address and expecting a certain response. However this wouldn't
be directly applicable to object signing certs, which contain identity
information, not domain-related info. So I'm not sure what you would do there.)

4.c. Finally a minor point of clarification: I know that Go Daddy offers a
"private domain registration" service that allows domain registrants to keep
their personal contact info out of the public whois database. I presume that
when such registrants apply for SSL certs through Go Daddy you do domain
ownership validation in the standard way, since Go Daddy has a record of the
registrant's email address even though it isn't public information. Is this correct?

Thanks in advance for providing answers to the above questions.

Comment 2

[Wayne Thayer (old account)]

Responses:

1.  Yes, these new roots will be published to the Go Daddy/Starfield 
Technologies repository soon
2.  The new roots are true self-signed roots that may be used as online 
issuing roots, or we may issue leaf certs from intermediate certs issued from 
these roots as we are doing with the Valicert Class 2 Root
3.  Yes, the new roots are considered Starfield Root CAs, and we will update 
the CPS to explicitly include these new roots.  No other changes are planned 
to the CPS at this time
4a.  Yes, that is correct.
4b.  Since we do not currently sell S/MIME or code signing certificates, no 
information is posted on how we would perform validation.  We will follow 
industry standard practices (i.e. email address control validation for S/MIME) 
and our processes will have to be approved by our WebTrust auditors.
4c.  Emails sent to the WHOIS contact for domains registered at Domains by 
Proxy are forwarded on to the actual registrant.  We don't have to do anything 
special to handle this case.

Please let me know if you need any further information.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Frank, after looking at https://www.godaddy.com/gdshop/ssl/ssl.asp and 
related pages, I observe that this CA is offering both low assurance and 
high assurance certs.  The basic issue is giving the user a chance to 
decide whether or not to trust the lower assurance CA separately from 
his decision to trust (or not) the higher assurance CA.

I hope these certs are not issued by the same issuer.  
I hope there are separate roots for these two classes of certs.  
Alternatively, there could be two separate intermediate CAs used, and
in that case, I think I'd suggest that those two ICAs be included with
mozilla, so that a user could choose to trust one but not the other.  

Wayne, do you know the answers to my questions?

Comment 4

[Wayne Thayer (old account)]

We currently use the same root and intermediate chain to issue both our high 
assurance and "domain control verified" certificates, so a relying party that 
chose not to trust our "domain control verified" certificates would also not 
trust our high assurance certificates.  The distinguishing characteristic of 
the two types of certificates is the information we populate in the subject 
field.

Having said that, I am in support of a standardized mechanism for 
distinguishing between assurance levels, whether that be a standardized 
subject field, a new assurance level OID, or a mechanism for identifying 
different types of intermediates.  I would try to make our usage of these new 
roots comply with any standard or consensus recommendation that emerges.

Comment 5

[Frank Hecker]

My apologies for getting distracted and neglecting this bug. Could you please
send me the root certificates (or attach them to this bug)? Then this week I can
contact you to verify the cert fingerprints.

Comment 6

[Wayne Thayer (old account)]

The root have been emailed to Frank Hecker.

Comment 7

[Frank Hecker]

The root certs are also up at the Go Daddy site, and I've linked to them from my
CA certificate list:

  http://www.hecker.org/mozilla/ca-certificate-list

I also called Go Daddy and verified the SHA-1 fingerprints on the new root certs:

Go Daddy Class 2 CA SHA-1 fingerprint:
  27 96 BA E6 3F 18 01 E2 77 26 1B A0 D7 77 70 02 8F 20 EE E4

Starfield Class 2 CA SHA-1 fingerprint:
  AD 7E 1C 28 B0 64 EF 8F 60 03 40 20 14 C3 D0 E3 37 0E B5 8A

Tomorrow I plan to approve these certs to be included in Firefox, Thunderbird,
etc., unless anyone has compelling arguments why I should not do this.

Comment 8

[Frank Hecker]

In accordance with current policy and per my prior comments, I'm approving the
two Go Daddy certs for inclusion in Firefox, Thunderbird, and other
Mozilla-related products distributed through mozilla.org. Going off now to file
a bug against NSS.

Comment 9

[Frank Hecker]

Resolving this bug as FIXED, since the necessary changes have been made to NSS
and will henceforth show up in future versions of Firefox, Thunderbird, etc.

Comment 10

[v-kestre]

Attachment: Audit Info for Starfield

Audit info for Starfield

Comment 11

[v-kestre]

Attachment: Starfield-BR-Audit Info-2016.pdf

Audit info

Comment 12

[v-kestre]

Attachment: Audit Info-Starfield-WTCA-2016

Audit info