Closed Bug 284677 Opened 15 years ago Closed 15 years ago
Add Go Daddy CA Cert to root store
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
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.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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.
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?
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.
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.
The root have been emailed to 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.
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.
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.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Audit info for Starfield
You need to log in before you can comment on or make changes to this bug.