527056 - Add Go Daddy CA Certs to root store

Status: RESOLVED FIXED

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

Description

[P Dolan]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 3.0.04506.30; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Build Identifier: 

Please add three 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.  Friendly names are: Go Daddy Root Certificate Authority - G2, Starfield Root Certificate Authority - G2, Starfield Services Root Certificate Authority - G2.  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 three 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, but will be added)
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:
NA
Actual Results:  
NA

Expected Results:  
NA

Comment 1

[David E. Ross]

> Please add three new Go Daddy root certificates to 
> the Mozilla/Firefox root store.

Does not Go Daddy support SeaMonkey, Camino, Thunderbird, and other Mozilla-based products?  The store of root certificates is not a Firefox component.  It's an NSS database used by a number of different products that use Gecko, both Mozilla products and other open-source products.

Comment 2

[P Dolan]

Yes, the certificates are compatable with the different Mozilla-based products and other open-source products.

Comment 3

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

The attached document summarizes the information that has been gathered and verified as per
https://wiki.mozilla.org/CA:How_to_apply#Information_gathering_and_verification
 
The items highlighted in yellow indicate where further information or clarification is needed. Please review the full document for accuracy and completeness.

Comment 4

[Rick Sloan]

lots of users telling me they get a message poping up in FF3.5 that says the certificate on our site is not good, when it is... this bug is the reason for it, have had at least 20 complaints now.... we have a go daddy cert

Comment 5

[Matthias Versen [:Matti]]

Sorry Kathleen this doesn't seem to be a valid root request, moving to Core:PSM for triage.

Reporter: You can not request that a Go Daddy root certificate should we added, that cone only be done by the CA issuer itself.
Can you provide an URL with your certificate ?
There is a Starfield root CA already included in Gecko.
Either your SSL setup is not correctly configured or your Certificate isn't included. in both cases you have to ask the go daddy support.

johnath: Can you help in this case ?

Comment 6

[Johnathan Nightingale [:johnath]]

 
(In reply to comment #5)
> Sorry Kathleen this doesn't seem to be a valid root request, moving to Core:PSM
> for triage.
> 
> Reporter: You can not request that a Go Daddy root certificate should we added,
> that cone only be done by the CA issuer itself.
> Can you provide an URL with your certificate ?
> There is a Starfield root CA already included in Gecko.
> Either your SSL setup is not correctly configured or your Certificate isn't
> included. in both cases you have to ask the go daddy support.
> 
> johnath: Can you help in this case ?

There might be two things going on, here. The original reporter has a Starfield email address, so this may well be a legitimate request to add new roots which complement or replace existing roots. Mr/Ms. Dolan - can you confirm this?

Comment 4, from Rick Sloan, is almost certainly a misconfigured server which is not sending the appropriate intermediates. Hard to know without a URL, but my guess is that Mr. Sloan just searched bugzilla go any mention of his CA and commented there. If Rick provides a URL, we can be sure, but his comment should not change the process that P Dolan initiated.

Kathleen, do you agree? If so, this should be moved back to CA Certificates to be evaluated, including a determination about whether Mr/Ms. Dolan is authorized to make the request on behalf of Go Daddy/Starfield. Mr. Sloan's complaint is orthogonal to this process, I strongly suspect.

Comment 7

[Matthias Versen [:Matti]]

I'm stupid -> moving back, i didn't recognized that comment#4 isn't from the original reporter.

Comment 8

[Rick Sloan]

(In reply to comment #4)
> lots of users telling me they get a message poping up in FF3.5 that says the
> certificate on our site is not good, when it is... this bug is the reason for
> it, have had at least 20 complaints now.... we have a go daddy cert

Sorry I confused things here I thought I was just helping as I was mentioning that I had the issue to... Starfield told me it was a FF issue when they investigated.... here is the an URL

https://www.myfmstation.com/store/login.php

Thanks.

Comment 9

[Eddy Nigg (StartCom)]

It's a misconfiguration at the server - and unfortunately it's not very helpful to blame the browser. The server must send the complete CA certificate chain up to the CA root. This server doesn't do that.

Comment 10

[Kathleen Wilson]

Hmmm.  That is interesting: "Starfield told me it was a FF issue"
Clearly it was not a FF issue... And it appears that the server is now correctly configured... Thanks to all who responded so promptly.

Mr./Ms. Dolan, please respond to Comment #3, in order to proceed with this request.

Comment 11

[P Dolan]

Yes, I do work for Go Daddy / Starfield Technology.  I was out of the office for a couple of days, but will quickly gather and post all the information for Comment #3.

Comment 12

[P Dolan]

I could not update the .pdf attached in Comment #3, but included all of the responses below. 

Cert Summary / Comments:
• "Is the 'Go Daddy Class 2 CA' root cert that is current included in Mozilla/NSS the old version of this root?" - YES
• "Is the 'Starfield Class 2 CA' root cert that is current included in Mozilla/NSS the old version of this root?" - YES
• "The old version of this root was not included in Mozilla/NSS.  Correct?" - CORRECT
NOTE: While the two certs are newer versions of existing roots, those existing roots must remain in Mozilla/NSS for the foreseeable future.

Root CA Certificate URLs:
• Go Daddy Root - G2: https://certificates.godaddy.com/repository/gdroot-g2.crt
• Starfield Root - G2: https://certificates.starfieldtech.com/repository/sfroot-g2.crt
• Starfield Services Root - G2: https://certificates.starfieldtech.com/repository/sfsroot-g2.crt

Test Website: https://gdg2roottest.godaddy.com/
https://sfg2roottest.starfieldtech.com/
https://sfsg2roottest.starfieldtech.com/

CRL URLs:
• Go Daddy Root - G2: http://crl.godaddy.com/gdroot-g2.crl
• Starfield Root - G2: http://crl.starfieldtech.com/sfroot-g2.crl
• Starfield Services Root - G2: http://crl.starfieldtech.com/sfsroot-g2.crl

CA Hierarchy:
• At this time, the new self-signed root CAs exist by themselves.  There are no plans to obtain cross-signed certificates from other CAs, nor are there any concrete plans for subordinate CAs.  When we reach a point where we intend to begin issuing from these roots, appropriate subordinate issuing CAs will be created, at least one per root CA.
Sub-CAs operated by 3rd parties:
• There are no plans to issue any subordinate CAs to 3rd parties.
Cross-Signing:
• There are no cross-certificates issued to any of the G2 roots.
Requested Trust Bits:
• Ideally we would request all trust bits.  However, they make the point in the Email Address Ownership/Control section that we need to show documentation about our verification practices for email addresses.  We do not currently have any such thing, as we have not been in the personal identity cert business (yet).

CP/CPS:
• A new version of our CPS that does include these new G2 roots has been approved by management.  That version is not yet published to the public repository.  I can send a new version via email or I can update the bug when it is published.

Audit:
• Our annual audit cycle is roughly June to June.  These new roots were created in September.  They have not been covered under an official audit period.  However, our WebTrust auditors were on site and present for the entirety of the root creation ceremony.  We should be able to obtain some kind of letter/statement from KPMG attesting to the soundness of that procedure (if Mozilla requires such a thing). 
Email Address Ownership / Control:
• Under discussion
Potentially Problematic Practices:
• Long Lived DV Certificates:
Our CPS permits up to 10 years.  Indeed, we did issue 10 year certificates in the past.  The CPS remains that way in order to cover those still-valid certificates.  We no longer issue 10-year certificates; the maximum lifetime we currently offer is 5 years.
• Wildcard DV SSL Certificates:
GoDaddy/Starfield do issue wildcard DV certificates.
• Delegation of Domain/Email validation to third parties:
GoDaddy/Starfield does not delegate any validation duties.  All vetting/verification/validation is performed by GoDaddy/Starfield.
• Issuing end entity certificates directly from roots:
GoDaddy/Starfield does not issue subscriber certificates directly from root CAs.  However, we do issue certificates directly from the roots for infrastructure purposes (OCSP responder certificates, timestamp authority certificates, and test certificates, such as the SSL test certificates used at the test URLs listed in this application).
• Allowing external entities to operate unconstrained subordinate CAs:
GoDaddy/Starfield have not, and have no plans to, issue subordinate CA certificates to third parties.
• Distributing generated private keys in PKCS#12 files:
As a policy, GoDaddy/Starfield do not ever generate or come into contact with subscriber private keys.
• Certificates referencing hostnames or private IP addresses:
GoDaddy/Starfield currently do issue certificates to private IP addresses and non-fully-qualified hostnames if a subscriber so requests.  All such requests are reviewed by a human RA prior to issuance.
• OCSP Responses signed by a certificate under a different root:
All GoDaddy/Starfield CAs generate OCSP responses using a certificate that is issued directly by the CA for which responses are being generated.  In other words, the "Go Daddy Root Certificate Authority - G2" directly issues an OCSP Response signing certificate, and that certificate is used in the OCSP responses for the "Go Daddy Root Certificate Authority - G2" (and likewise for our other CAs).
• CRL with critical CIDP Extension
GoDaddy/Starfield CRLs do not include a CIDP extension.
• Generic Names for CAs:
The three CAs submitted in this application all are clearly labeled in the Subject with the names of the companies that own them.

Comment 13

[Kathleen Wilson]

Thank you for the information.

> CRL URLs:
> • Go Daddy Root - G2: http://crl.godaddy.com/gdroot-g2.crl
> • Starfield Root - G2: http://crl.starfieldtech.com/sfroot-g2.crl
> • Starfield Services Root - G2: http://crl.starfieldtech.com/sfsroot-g2.crl

The CRL Distribution point in each test cert is one of the above CRL URLs. However, the NextUpdate for each of those CRLs is 1 year, so I think those CRLs are intended mostly for the sub-CAs, and that the CRLs for end-entity certs haven’t been created yet because no sub-CA has been created.  Correct?

From CPS section 4.4.9 CRL Issuance Frequency: Issuing CAs -Every 7 days or less

So what will the NextUpdate be set to for the CRLs for end-entity certs?

> CA Hierarchy:
> • At this time, the new self-signed root CAs exist by themselves.  
> When we reach a point where we intend to begin issuing from these roots, 
> appropriate subordinate issuing CAs will be created, at least one per root CA.

Do you expect that the CA hierarchy for each new root will end up being similar to the current CA hierarchy of the old root?  If yes, can you provide a description and/or diagram of the current CA hierarchy of each old root? If not, please provide further info about your expectations of what the future CA hierarchy will be.

> Requested Trust Bits:
> • Ideally we would request all trust bits.  However, they make the point in 
> the Email Address Ownership/Control section that we need to show documentation
> about our verification practices for email addresses.  We do not currently 
> have any such thing, as we have not been in the personal identity cert 
> business(yet).

My recommendation is that we proceed with requesting the websites and code signing trust bits. If you decide to, you can file a new bug in the future to enable the email trust bit.

> CP/CPS:
> • A new version of our CPS that does include these new G2 roots has been
> approved by management.  That version is not yet published to the public
> repository.  I can send a new version via email or I can update the bug when 
> it is published.

Please post here in the bug when the new CPS is published.  We can proceed for now with the old CPS.

> Audit:
> • Our annual audit cycle is roughly June to June.  These new roots were 
> created in September.  They have not been covered under an official audit . 
> period However, our WebTrust auditors were on site and present for the 
> entirety of the root creation ceremony.  We should be able to obtain some 
> kind of letter/statement from KPMG attesting to the soundness of that 
> Mprocedure (if Mozilla requires such a thing). 

We’ll proceed for now with the current audit report.

> Potentially Problematic Practices:
> • Long Lived DV Certificates:
> Our CPS permits up to 10 years.  Indeed, we did issue 10 year certificates in
> the past.  The CPS remains that way in order to cover those still-valid
> certificates.  We no longer issue 10-year certificates; the maximum lifetime 
> we currently offer is 5 years.

From CPS section 7.1.4: One to ten years after Certificate issuance (depending on SSL certificate type).

I wasn’t able to find the maximum lifetime corresponding to each SSL certificate type. I need to specifically know what the maximum lifetime is for the DV (Medium assurance) certs.

Were the 10-year certs that you issued DV or OV?

> • Wildcard DV SSL Certificates:
> GoDaddy/Starfield do issue wildcard DV certificates.

What steps are taken to mitigate the risks associated with this practice?

> • Certificates referencing hostnames or private IP addresses:
> GoDaddy/Starfield currently do issue certificates to private IP addresses and
> non-fully-qualified hostnames if a subscriber so requests.  All such requests
> are reviewed by a human RA prior to issuance.

What does the human RA look for when they review such requests? 

A separate question…

What levels of assurance (Medium, High, EV) are applicable to “Starfield Services Root Certificate Authority - G2”?

Comment 14

[P Dolan]

Please see the responses included below.  

> CRL URLs:
> • Go Daddy Root - G2: http://crl.godaddy.com/gdroot-g2.crl
> • Starfield Root - G2: http://crl.starfieldtech.com/sfroot-g2.crl
> • Starfield Services Root - G2: http://crl.starfieldtech.com/sfsroot-g2.crl

The CRL Distribution point in each test cert is one of the above CRL URLs.
However, the NextUpdate for each of those CRLs is 1 year, so I think those CRLs are intended mostly for the sub-CAs, and that the CRLs for end-entity certs haven’t been created yet because no sub-CA has been created.  Correct?

RESPONSE: Correct.

From CPS section 4.4.9 CRL Issuance Frequency: Issuing CAs -Every 7 days or
less

So what will the NextUpdate be set to for the CRLs for end-entity certs?

RESPONSE: CRLs issued by subCAs that will generally contain entries for end-entity certificates are typically issued every 24 hours.  This is the case with all of our currently operating subCAs.  However we reserve the right to extend that up to a maximum of 7 days as specified in our CPS should it be required or desired in specific circumstances.

> CA Hierarchy:
> • At this time, the new self-signed root CAs exist by themselves.  
> When we reach a point where we intend to begin issuing from these roots, 
> appropriate subordinate issuing CAs will be created, at least one per root CA.

Do you expect that the CA hierarchy for each new root will end up being similar to the current CA hierarchy of the old root?

RESPONSE: Yes, at this time we expect it will be very similar to the hierarchy of the current roots.  At present, we do not expect to have any cross-certificates for the new roots.  However, if we need or want to start making use of the newer root certificates before they have achieved a sufficient level of distribution amongst the installed base of various software products, we may elect to issue cross-certificates to the new roots from the existing Go Daddy and Starfield root CAs (but not the from the Valicert root).

If yes, can you provide a description and/or diagram of the current CA hierarchy of each old root? If not, please provide further info about your expectations of what the future CA hierarchy will be.

RESPONSE: Will attach the diagram of our current hierarchy as requested.  Note that this diagram does NOT show the G2 roots; it shows the current CA hierarchy in operation today.

> Requested Trust Bits:
> • Ideally we would request all trust bits.  However, they make the point in 
> the Email Address Ownership/Control section that we need to show documentation
> about our verification practices for email addresses.  We do not currently 
> have any such thing, as we have not been in the personal identity cert 
> business(yet).

My recommendation is that we proceed with requesting the websites and code
signing trust bits. If you decide to, you can file a new bug in the future to
enable the email trust bit.

> CP/CPS:
> • A new version of our CPS that does include these new G2 roots has been
> approved by management.  That version is not yet published to the public
> repository.  I can send a new version via email or I can update the bug when 
> it is published.

Please post here in the bug when the new CPS is published.  We can proceed for now with the old CPS.

RESPONSE: The new CPS is now published at https://certs.starfieldtech.com/repository/.

> Audit:
> • Our annual audit cycle is roughly June to June.  These new roots were 
> created in September.  They have not been covered under an official audit . 
> period However, our WebTrust auditors were on site and present for the 
> entirety of the root creation ceremony.  We should be able to obtain some 
> kind of letter/statement from KPMG attesting to the soundness of that 
> Mprocedure (if Mozilla requires such a thing). 

We’ll proceed for now with the current audit report.

> Potentially Problematic Practices:
> • Long Lived DV Certificates:
> Our CPS permits up to 10 years.  Indeed, we did issue 10 year certificates in
> the past.  The CPS remains that way in order to cover those still-valid
> certificates.  We no longer issue 10-year certificates; the maximum lifetime 
> we currently offer is 5 years.

From CPS section 7.1.4: One to ten years after Certificate issuance (depending on SSL certificate type).

I wasn’t able to find the maximum lifetime corresponding to each SSL
certificate type. I need to specifically know what the maximum lifetime is for the DV (Medium assurance) certs.

Were the 10-year certs that you issued DV or OV?

RESPONSE: The 10 year certificates were all DV.

> • Wildcard DV SSL Certificates:
> GoDaddy/Starfield do issue wildcard DV certificates.

What steps are taken to mitigate the risks associated with this practice?

RESPONSE: At present, there are no extra steps taken in the validation process of a wildcard DV certificate beyond that of a non-wildcard DV certificate.  The debate over what level of risk actually exists from wildcard certificates is ongoing and certainly not decided.  We believe that there are good measures that browsers can take, such as highlighting the actual domain portion in the address bar (highlighting "example.com" in the case of "paypal.example.com") that are very beneficial in helping end users determine which site they are actually visiting.  We also do not believe that this is an issue unique to DV certificates.

> • Certificates referencing hostnames or private IP addresses:
> GoDaddy/Starfield currently do issue certificates to private IP addresses and
> non-fully-qualified hostnames if a subscriber so requests.  All such requests
> are reviewed by a human RA prior to issuance.

What does the human RA look for when they review such requests?

RESPONSE: First, all requests (regardless of the name(s) being requested) are automatically screened through an extensive list of strings intended to flag any name that may be used in fraud, phishing, etc.  In the case of non-TLD names, a human RA will further evaluate the name looking for any signs of homoglyph attacks or other visual issues with the name.  For both non-TLD names and IP addresses, our process:

1)  Verifies that the name or IP cannot be resolved/routed on the public Internet,

and

2)  Verifies that there are no signs of attempted fraud using both automated and manual methods.

A separate question…

What levels of assurance (Medium, High, EV) are applicable to “Starfield
Services Root Certificate Authority - G2”?  

RESPONSE: Medium, High and EV

Comment 15

[P Dolan]

Attachment: CA Hierarchy

Added CA Hierarchy Diagram

Comment 16

[Kathleen Wilson]

Thank you for the information. I think there is enough information to move forward with this request for inclusion of the “Go Daddy Root Certificate Authority - G2” and the “Starfield Root Certificate Authority - G2” root certificates with enablement of the Websites and Code Signing Trust bits.

However, I don’t think there is enough information to include the “Starfield Services Root Certificate Authority - G2” root certificate and enable any of the trust bits. All we know about this root is that it is “Reserved for future use.”

My recommendation is that we postpone the root inclusion request for the “Starfield Services Root Certificate Authority - G2” root certificate until there is a more concrete plan about what it will be used for. Do you agree?

Comment 17

[P Dolan]

Thank you very much for moving forward with the "Go Daddy Root Certificate Authority - G2" and the "Starfield Root Certificate Authority - G2".

Can we have the "Starfield Services Root Certificate Authority - G2" included at the same time?  As a CA, we have to get our root certs distributed amongst a wide enough portion of the installed base before they are usable for anything.  This usually means that the roots need to be published for some time before they are actually intended to be used.

Regarding the future use, we may use this root to anchor new services such as S/MIME certificates, or services that are required by laws or standards to run under a distinct trust anchor.

Do you know what the date and the version number of the Firefox release and the NSS release?

Thank you for your help.

Comment 18

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 19

[Kathleen Wilson]

This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

> Can we have the "Starfield Services Root Certificate Authority - G2" included
> at the same time?  As a CA, we have to get our root certs distributed amongst 
> a wide enough portion of the installed base before they are usable for 
> anything. This usually means that the roots need to be published for some 
> time before they are actually intended to be used.

This doesn’t usually fly, but for now I'll keep the root in the info gathering document, and have it be part of the public discussion. Note that it is very likely that the outcome of the public discussion will be that this root not be included until there are more concrete plans for it.

> Do you know what the date and the version number of
> the Firefox release and the NSS release?

Please see: https://wiki.mozilla.org/CA:How_to_apply#Timeline

Comment 20

[Kathleen Wilson]

This request is approaching the top of the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

As such, I would like to update the Information Gathering Document with any new information.

The roots in this inclusion request are:
Go Daddy Root Certificate Authority - G2
Starfield Root Certificate Authority - G2
Starfield Services Root Certificate Authority - G2

Do you have more concrete plans for the CA hierarchy that will be implemented under each of these roots? 
Have any intermediate CAs been created under any of these roots?
Are these roots being included in the current audit?

Comment 21

[P Dolan]

Thank you for the update.  

For the "Go Daddy Root Certificate Authority - G2" and the "Starfield Root Certificate Authority - G2", they will be eventual replacements for the existing Go Daddy and Starfield roots already included in Mozilla.  Intermediate CAs will be issued from them, and those Intermediates will be used to issue subscriber SSL and Code Signing certificates, and possibly other types of certificates in the future.

For the "Starfield Services Root Certificate Authority - G2” our current plans are considering this as an anchor for new services such as S/MIME or services that are required by laws or standards to under a distinct trust anchor.  

No intermediate CAs have been created yet.  We feel the roots need to achieve proper penetration amongst the software vendors before they are of sufficient use to us to proceed with issuance plans.  Once we have significant penetration, we will begin the replacement and phasing out the older roots already included in Mozilla.  

These 3 new roots are included in the scope of our July 2009 / June 2010 audit period.

Comment 22

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 23

[Kathleen Wilson]

I am now opening the first public discussion period for this request from Go Daddy to add three root certificates: 
1) Go Daddy Root Certificate Authority - G2
2) Starfield Root Certificate Authority - G2
3) Starfield Services Root Certificate Authority - G2

This request is to enable the Websites and Code Signing trust bits for all three roots. 

This request is to enable EV for the “Go Daddy Root Certificate Authority - G2” and “Starfield Root Certificate Authority - G2” roots.

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 “Go Daddy Root Inclusion Request”

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

A representative of Go Daddy must promptly respond directly in the discussion thread to all questions that are posted.

Comment 24

[Kathleen Wilson]

The public discussion for this request is now closed. 

This request from Go Daddy is to add three root certificates, enable the Websites and Code Signing trust bits for all three, and enable EV for the “Go Daddy Root Certificate Authority - G2” and “Starfield Root Certificate Authority - G2” roots.

The discussion resulted in the following two action items.

1) ACTION Go Daddy: Update CPS to state that as of a certain date DV certificates are no longer issued with validity longer than 5 years.

2) ACTION Go Daddy: Update CPS to clarify re-validation procedures for long-lived DV certs. Indicate frequency of re-validation, and steps taken to confirm that the certificate subscriber still owns/controls the domain that is included in the cert.

Please post updates into this bug as these action items are completed, and include links to the updated documentation.

After I have confirmed that the action items have been satisfactorily completed, I plan to recommend approval of this request.

Comment 25

[Ryan Koski]

Version 2.8 of our CP/CPS is now published in our public repository at:

https://certs.godaddy.com/repository

This version addresses the requirements in Comment 24.  Specifically, a note was added to Section 6.3.2 covering Action Item #1, and Section 3.1.8 was added covering Action Item #2.

Comment 26

[Kathleen Wilson]

In version 2.8 of the CP/CPS:
https://certs.starfieldtech.com/repository/StarfieldCP-CPS.pdf

The following was added in section 6.3.2:
"** As of June 2, 2009, the maximum validity period available for new subscriber certificate purchases is 5 years."

This completes Action Item #1 a per Comment 24.


The following was added in section 3.1.8:
"Verification of domain name access is performed when a domain name is first requested for a certificate in a given customer account. Once a certificate has been issued, no further verification of the domain name(s) within the certificate is performed during the validity period of the issued certificate. Verification of domain name access is performed when a Subscriber requests the renewal of a certificate, but only if the previous verification was performed more than 13 months prior to the renewal request. (see §3.2 -- §3.4)."

While this meets the requirement as stated in Action Item #2 in Comment 24, it does not meet the requirement of Version 2.0 of the Mozilla CA Certificate Policy (which is expected to be approved this week).

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
6. We require that all CAs whose certificates are distributed with our software products: 
...
- verify that all of the information that is included in SSL certificates remains current and correct at time intervals of thirty-nine months or less;

Comment 27

[Ryan Koski]

The original bug was filed in November of 2009.  The discussion period and action items were decided in November/December of 2010.  I would argue that the Action Items should be evaluated in the context of the then-current Mozilla policy which does not include the language you quote above.  Otherwise, it is theoretically possible that a CA will be continually chasing policy changes.  I could set out to modify our CPS again to bring it in line with v2.0 of the policy, only to discover that v2.1 has been published in the meantime and I need to now modify my CPS again prior to approval.

With regard to the specific change you highlight above (re-verification of information), surely you understand that it will take some amount of time for CAs to update their procedures and CP/CPS documents to align with that requirement.  So, if v2.0 of the policy is approved this week, is it Mozilla's intention to immediately disable the trust bits on existing CAs until the CAs prove compliance with the new rules?  I would hope the obvious answer is "no".  Therefore, at the point where this policy is adopted, many if not most of the existing CAs will not be in compliance with the policy.  I do not see how that is a reason to deny this particular root inclusion request.

Comment 28

[Kathleen Wilson]

CAs will be notified of the new version of the Mozilla CA Policy when it is approved/published. They will then have 6 months to comply. Given the timing of this request and that it is for renewed roots, I agree that the CA should have this 6 month period to comply for these new roots.

I will proceed with recommending approval of this request.

Comment 29

[Kathleen Wilson]

This request has been evaluated as per the Mozilla CA Certificate 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 from Go Daddy to add three root certificates:
1) Go Daddy Root Certificate Authority - G2
2) Starfield Root Certificate Authority - G2
3) Starfield Services Root Certificate Authority - G2

The request is to enable the Websites and Code Signing trust bits for all three roots. 

The request is also to enable EV for the “Go Daddy Root Certificate Authority - G2” and “Starfield Root Certificate Authority - G2” roots.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by Go Daddy, 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]. Go Daddy appears to provide a service relevant to Mozilla users: It is a commercial CA based in the US and serving customers worldwide. The Go Daddy Group of companies includes Wild West Domains, Inc., a reseller of domains and domain-related products and services; Domains By Proxy, a private registration service; Starfield Technologies, a research and development affiliate; and Blue Razor Domains, a membership-based discount registrar.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list. The main documents of interest are the CP/CPS and the Subscriber Agreements, which are in English. 

CP/CPS: https://certs.starfieldtech.com/repository/StarfieldCP-CPS.pdf
Document Repository: https://certs.godaddy.com/repository
Subscriber Agreements:
https://certs.starfieldtech.com/repository/StarfieldSubscriberAgreement.pdf
https://certs.starfieldtech.com/repository/StarfieldEVSubscriberAgreement.pdf
https://certs.starfieldtech.com/repository/StarfieldCodeSigningCertificateSubscriberAgreement_1.0.pdf

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

* Email: Not applicable. Go Daddy is not requesting enablement of the Email trust bit for these roots at this time.

* SSL: According to the CP/CPS sections 3.1.8 through 3.1.11, for both Medium and High Assurance SSL certificates, Starfield verifies that the subscriber requesting the certificate has access to the domain name(s) that are specified in the certificate application. Medium Assurance certs are DV. High Assurance certs are OV. For High Assurance organizational Subscribers, Starfield also verifies the organization name represents an organization currently registered with a government authority, and the individual requesting the certificate is authorized to do so by the organization named in the certificate

* Code: CPS Section 3.1.13: For High Assurance Code Signing Subscribers, Starfield verifies that the organization name represents an organization currently registered with a government authority, and that the individual requesting the certificate is authorized to do so by the organization named in the certificate.

* EV Policy OIDS
** “Go Daddy Root Certificate Authority - G2” – 2.16.840.1.114413.1.7.23.3
** “Starfield Root Certificate Authority - G2” – 2.16.840.1.114414.1.7.23.3
** “Starfield Services Root Certificate Authority - G2” – not applicable

Section 13 [Certificate Hierarchy]

* “Go Daddy Root Certificate Authority - G2” is a SHA256 root that will eventually replace the “Go Daddy Class 2 CA” root cert that is currently included in NSS. This root will sign internally-operated intermediate CAs for issuing subscriber SSL and Code Signing certificates, and possibly other types of certificates in the future.

* “Starfield Root Certificate Authority - G2” is a SHA256 root that will eventually replace the “Starfield Class 2 CA” root cert that is currently included in NSS.This root will sign internally-operated intermediate CAs for issuing subscriber SSL and Code Signing certificates, and possibly other types of certificates in the future.

* “Starfield Services Root Certificate Authority - G2” is reserved for future use. Current plans are to have this root be an anchor for new services such as S/MIME or services that are required by laws or standards to be under a distinct trust anchor.

Other: 

* Go Daddy issues CRLs with NextUpdate 7 days or less for end-entity certs.
* OCSP is provided.

 * CP/CPS section 6.3.2: As of June 2, 2009, the maximum validity period available for new subscriber certificate purchases is 5 years.
** Currently no re-verification is done on long-lived certificates. Go Daddy is aware of the new requirement in Version 2.0 of the Mozilla CA Certificate Policy, that will require re-verification at time intervals of 39 months or less. CAs will have six months to update their processes and documentation to meet the requirements of the new policy.

* CP/CPS section 7.1.4: 
** medium assurance: CN = domain name of Subscriber’s web site (may be fully qualified, wildcard, contain no periods, or IP address reserved for internal use)
** high assurance:  CN = domain name of Subscriber’s web site (may be fully qualified, wildcard, contains no periods, or IP address reserved for internal use)
*** At present, there are no extra steps taken in the validation process of a wildcard DV certificate beyond that of a non-wildcard DV certificate.  
*** GoDaddy/Starfield currently do issue certificates to private IP addresses and non-fully-qualified hostnames if a subscriber so requests.  All such requests are reviewed by a human RA prior to issuance.
*** All requests (regardless of the name(s) being requested) are automatically screened through an extensive list of strings intended to flag any name that may be used in fraud, phishing, etc.  In the case of non-TLD names, a human RA will further evaluate the name looking for any signs of homoglyph attacks or other visual issues with the name.  For both non-TLD names and IP addresses, the RA: 1) Verifies that the name or IP cannot be resolved/routed on the public Internet, and 2)  Verifies that there are no signs of attempted fraud using both automated and manual methods.

Section 8-10 [Audit]. 
KPMG performs annual audits according to the WebTrust CA and WebTrust EV criteria, and the audit reports are posted on the webtrust.org website at https://cert.webtrust.org/SealFile?seal=355&file=pdf 
** These G2 roots are included in the audit reports.

Based on this assessment I intend to approve this request to add the “Go Daddy Root Certificate Authority - G2”, “Starfield Root Certificate Authority - G2”, and “Starfield Services Root Certificate Authority - G2” root certificates, and enable the Websites and Code Signing trust bits. I also intend to approve this request to enable EV for the “Go Daddy Root Certificate Authority - G2” and “Starfield Root Certificate Authority - G2” root certificates.

Comment 30

[Kathleen Wilson]

To the representatives of Go Daddy: 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 in Comment #29, and on behalf of the Mozilla project I
approve this request from Go Daddy to include the following root certificates
in Mozilla:

* Go Daddy Root Certificate Authority - G2 (websites, code signing), enable EV.

* Starfield Root Certificate Authority - G2 (websites, code signing), enable EV.

* Starfield Services Root Certificate Authority - G2 (web sites, code signing)

I will file the NSS and PSM bugs to effect the approved changes.

Comment 31

[Kathleen Wilson]

I have filed bug 632461 against NSS and bug 632475 against PSM for the actual changes.

Comment 32

[Kathleen Wilson]

Attachment: 2013 KPMG Baseline Audit Statement.pdf