Go Daddy Root Inclusion Request
Kathleen Wilson
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 also to enable EV for the �Go Daddy Root Certificate
Authority - G2� and �Starfield Root Certificate Authority - G2� roots.
Go Daddy 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.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=527056
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Go%20Daddy
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=455489
Noteworthy points:
* �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 under a distinct trust anchor.
* The CP and CPS documents are in English.
CP/CPS: https://certs.starfieldtech.com/repository/StarfieldCP-CPS.pdf
* The request is to enable the Websites and Code Signing trust bits for
all three roots.
* 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
**
https://certs.starfieldtech.com/repository/StarfieldSubscriberAgreement.pdf
* Code Signing: CPS Section 3.1.13: For High Assurance Code Signing
Subscribers, Starfield verifies the following:
** the organization name represents an organization currently registered
with a government Authority
** the individual requesting the certificate is authorized to do so by
the organization named in the certificate
**
https://certs.starfieldtech.com/repository/StarfieldCodeSigningCertificateSubscriberAgreement_1.0.pdf
* 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
** CP/CPS section 3.1.12: For Extended Validation Subscribers, Starfield
verifies the following in accordance with the CA/Browser Forum
Guidelines for the Issuance and Management of Extended Validation
Certificates:
*** Legal Existence and Identity
*** Assumed Name (optional)
*** Physical Existence
*** Operational Existence (if records indicate that the organization is
less than three years old)
*** Domain ownership or exclusive right to use
*** Name, title, and authority of contract signer, and certificate approver
**
https://certs.starfieldtech.com/repository/StarfieldEVSubscriberAgreement.pdf
** https://certs.starfieldtech.com/repository/AccountantLetterTemplate.pdf
** https://certs.starfieldtech.com/repository/LegalOpinionTemplate.pdf
**
https://certs.starfieldtech.com/repository/EV_Principal_Attestation_Starfield.pdf
* Test Websites:
** https://gdg2roottest.godaddy.com/
** https://sfg2roottest.starfieldtech.com/
** https://sfsg2roottest.starfieldtech.com/
** Note: No sub-CAs have yet been created for these roots, so the test
certs are signed directly by the roots.
* CRL:
** http://crl.godaddy.com/gdroot-g2.crl
** http://crl.starfieldtech.com/sfroot-g2.crl
** http://crl.starfieldtech.com/sfsroot-g2.crl
** CRLs for end-entity certs haven�t been created yet because no sub-CA
has been created.
** CP/CPS section 4.4.9 CRL Issuance Frequency: Issuing CAs -- Every 7
days or less
* OCSP:
** http://ocsp.godaddy.com
** http://ocsp.starfieldtech.com
** http://ocsp.starfieldtech.com
** CP/CPS section 4.4.11 Online Revocation/Status Checking Availability:
Issuing CAs -- Every 4 days or less
* Other:
** CP/ CPS section 7.1.4: One to ten years after Certificate issuance
(depending on SSL certificate type).
*** Comment: Our CPS permits up to 10 years. Indeed, we did issue 10
year DV 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.
** 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)
*** Comment: 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.
*** Comment : 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.
*** Comment: 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.
* 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 (2010.06.30).
** These G2 roots are included in the audit reports.
This begins a one-week discussion period. After that week, I will
provide a summary of issues noted and action items. If there are no
outstanding issues, then this request can be approved. If there are
outstanding issues or action items, then an additional discussion may be
needed as follow-up.
Kathleen
Kathleen Wilson
> Go Daddy has applied 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.
>
> Authority - G2” and “Starfield Root Certificate Authority - G2” roots.
>
> Go Daddy 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.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=527056
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#Go%20Daddy
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=455489
>
All, Would at least two of you please review and comment on this request?
I will greatly appreciate your input.
Kathleen
Eddy Nigg
> All, Would at least two of you please review and comment on this request?
Yes, will do so soon.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Leonardo Segovia
I'd like to ask a small question about GoDaddy's CA practices.
In the hypothetic case that someone requests a SSL certificate for a website
(be it middle, high assurance or EV) which is later found to be distributing
bogus software or even malware, what is the procedure for these cases?
I'm asking because a year ago I came across a site which was selling a bogus
AV app -under a SSL connection secured by another reputable Certification
Authority. (1)
Yours sincerely,
Leo Segovia
____
(1) The site I was referring to is mentioned in a ForoSpyware topic at
http://www.forospyware.com/t240508.html
P/S: I'm resending the message because it seems that the spam filtering
blocked my fake address (leo.w...@mozilla.newsgroup.nospam)
"Kathleen Wilson" <kathle...@yahoo.com> escribió en el mensaje de
noticias:mailman.197.1288814284.1...@lists.mozilla.org...
>
> All, Would at least two of you please review and comment on this request?
>
> I will greatly appreciate your input.
> Kathleen
>
>
> ---
> avast! Antivirus: Inbound message clean.
> Virus Database (VPS): 101103-1, 03/11/2010
> Tested on: 03/11/2010 09:20:53 p.m.
> avast! - copyright (c) 1988-2010 AVAST Software.
> http://www.avast.com
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 101103-1, 03/11/2010
Tested on: 03/11/2010 10:27:07 p.m.
avast! - copyright (c) 1988-2010 AVAST Software.
http://www.avast.com
Peter Gutmann
>In the hypothetic case that someone requests a SSL certificate for a website
>(be it middle, high assurance or EV) which is later found to be distributing
>bogus software or even malware, what is the procedure for these cases?
According to AV vendors who've tried getting such certs revoked, the actual
(rather than documented-in-the-CPS) procedure is for the CA to ignore any
complaints in relation to this issue.
(Oh, and it's not hypothetical, there are quite a number of malware sites that
use CA-issued certs, and have been for some time. Just browse a few PPI
(malware pay-per-install) sites for example...).
Peter.
Leonardo Segovia
practice.
Anyway, I am waiting to see if a Go Daddy representative can state what
their plans are in case something lke this happen (a SSL cert licensed under
the new G2 roots).
Off-topic: This could be another point to add to the updated Mozilla CA
Policy.
Leo
"Peter Gutmann" <pgu...@cs.auckland.ac.nz> escribió en el mensaje de
noticias:mailman.230.1288847841.1...@lists.mozilla.org...
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 101104-0, 04/11/2010
Tested on: 04/11/2010 11:10:21 a.m.
Leonardo Segovia
I'd like to ask a small question about GoDaddy's CA practices.
In the hypothetic case that someone requests a SSL certificate for a website
(be it middle, high assurance or EV) which is later found to be distributing
bogus software or even malware, what is the procedure for these cases?
I'm asking because a year ago I came across a site which was selling a bogus
AV app -under a SSL connection secured by another reputable Certification
Authority. (1)
Yours sincerely,
Leo Segovia
____
(1) The site I was referring to is mentioned in a ForoSpyware topic at
http://www.forospyware.com/t240508.html
"Kathleen Wilson" <kathle...@yahoo.com> escribió en el mensaje de
noticias:mailman.197.1288814284.1...@lists.mozilla.org...
>
> All, Would at least two of you please review and comment on this request?
>
> I will greatly appreciate your input.
> Kathleen
>
>
> ---
> avast! Antivirus: Inbound message clean.
> Virus Database (VPS): 101103-1, 03/11/2010
> Tested on: 03/11/2010 09:20:53 p.m.
> avast! - copyright (c) 1988-2010 AVAST Software.
> http://www.avast.com
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 101103-1, 03/11/2010
Tested on: 03/11/2010 09:55:30 p.m.
Patrick Dolan
In the event that GoDaddy/Starfield is notified of either
a web site using one of our certificates to deliver malware,
or an organization has signed and distributed malware using
one of our Code Signing certificates, we will conduct our
own investigation to determine the nature of the alleged
offense. If GoDaddy/Starfield determines that the Subscriber
is in violation of the Subscriber Agreement, the certificate
will be revoked.
Our CP/CPS, in Section 4.4.1, states that "A certificate may be
revoked under any or all of the following circumstances...
The Subscriber can be shown to have violated the stipulations of
the Subscriber Agreement."
For Medium and High Assurance SSL/TLS certificates, see sections
III.(e) and V.(g) of the Subscriber Agreement:
https://certs.starfieldtech.com/repository/StarfieldSubscriberAgreement.pdf
For EV certificates, see sections III.(e) and V.(g) of the EV
Subscriber Agreement:
https://certs.starfieldtech.com/repository/StarfieldEVSubscriberAgreement.pdf
For Code Signing certificates, see sections III.(e), III.(g),
and V.(g) of the Code Signing Subscriber Agreement:
Leonardo Segovia
Yours sincerely,
Leo Segovia
"Patrick Dolan" <pdo...@godaddy.com> escribió en el mensaje de
noticias:mailman.273.1288903767.1...@lists.mozilla.org...
> Here is the Go Daddy / Starfield response:
>
> In the event that GoDaddy/Starfield is notified of either
> a web site using one of our certificates to deliver malware,
> or an organization has signed and distributed malware using
> one of our Code Signing certificates, we will conduct our
> own investigation to determine the nature of the alleged
> offense. If GoDaddy/Starfield determines that the Subscriber
> is in violation of the Subscriber Agreement, the certificate
> will be revoked.
>
> Our CP/CPS, in Section 4.4.1, states that "A certificate may be
> revoked under any or all of the following circumstances...
> The Subscriber can be shown to have violated the stipulations of
> the Subscriber Agreement."
>
> For Medium and High Assurance SSL/TLS certificates, see sections
> III.(e) and V.(g) of the Subscriber Agreement:
>
> https://certs.starfieldtech.com/repository/StarfieldSubscriberAgreement.pdf
>
> For EV certificates, see sections III.(e) and V.(g) of the EV
> Subscriber Agreement:
>
> https://certs.starfieldtech.com/repository/StarfieldEVSubscriberAgreement..pdf
>
> For Code Signing certificates, see sections III.(e), III.(g),
> and V.(g) of the Code Signing Subscriber Agreement:
>
> https://certs.starfieldtech.com/repository/StarfieldCodeSigningCertificateSubscriberAgreement_1.0.pdf
>
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 101104-0, 04/11/2010
Tested on: 04/11/2010 09:01:51 p.m.
Eddy Nigg
> ** CP/ CPS section 7.1.4: One to ten years after Certificate issuance
> (depending on SSL certificate type).
> *** Comment: Our CPS permits up to 10 years. Indeed, we did issue 10
> year DV 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.
If Godaddy doesn't issue such certificates anymore it should update the
CPS accordingly. This obviously doesn't affect certificates which were
issued under a different policy. However competing CAs have many times
pointed to Godaddy regarding long-living certificates and I believe it's
at the time to correct it.
Additionally I believe that five years are a long period too. Does
Godaddy enforce a revalidation requirement after a certain period?
Godaddy might be easily in the position to know about changes of domain
names holders.
>
> ** 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)
Does Godaddy indeed issue certificates to internal IP addresses like
192.168.1.2 and non-qualified host names? Which verification has Godaddy
performed for such host names?
Please note that the current Mozilla CA Policy requires that the CA
takes reasonable measures to verify that the entity submitting the
certificate signing request has registered the domain(s) referenced in
the certificate /or/ has been authorized by the domain registrant to act
on the registrant's behalf.
This doesn't include non-qualified host names and IP addresses,
certainly not Class B/C IP addresses.
> *** Comment : 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.
Apparently Godaddy does...and I believe this should be addressed.
Nelson Bolyard
Of course, a code signing certificate is not an attestation of the
morality, trustworthiness, programming skills, or any other "goodness"
of the party to whom it is issued. It merely provides a way for the
party who wrote the code to identify it as his, to segregate his own
code from that of someone else, and to take responsbility for his own
code. It provides a way for others to know who to hold responsible
for the code they obtain.
The whole idea that code signing certs should mean something else is silly.
--
/Nelson Bolyard
Ryan Koski
>
> If Godaddy doesn't issue such certificates anymore it should update the
> CPS accordingly. This obviously doesn't affect certificates which were
> issued under a different policy.
GoDaddy/Starfield do not use distinct policy OIDs to denote
different certificate lifetimes. To do so would be problematic
for several reasons, not the least of which are certificate rekeys
which result in variable certificate lifetimes (but not exceeding
a maximum duration). Our policy OIDs denote the level of
vetting performed when issuing a given certificate as documented
in our CP/CPS. Therefore, the comment that "This obviously doesn't
affect certificates which were issued under a different policy" is
incorrect. The certificates were all issued under the same policy
OID.
Therefore, we feel it is appropriate to leave our CP/CPS as is,
to cover the existing certificates in the field.
> Additionally I believe that five years are a long period too.
We appreciate that you have your own opinion on certificate lifetime
maximums. However, the current Mozilla CA Policy does not have
defined maximums. We understand that this issue is currently being
debated in the CABForum, and once something formal is approved we
will make the necessary adjustments. For the purposes of our current
root submission request, however, there is no official policy that
governs
certificate lifetimes. Therefore we believe this issue to be out of
scope.
> Does Godaddy indeed issue certificates to internal IP addresses like
> 192.168.1.2 and non-qualified host names? Which verification has Godaddy
> performed for such host names?
The issue of non-qualified hostnames and RFC1918 IP addresses is yet
another issue currently being debated in the CABForum with no official
policy being adopted yet. Yes, the official wording of the current
Mozilla CA policy is as you quote. However, there have certainly been
root CAs that have successfully been admitted to the Mozilla Root
program
recently that also issue to non-qualified names and private IP
addresses.
So while the policy has language that can be interpreted to be a ban
on
such practices, there is precedent from Mozilla that CAs who do issue
such certificates will be admitted. To deny our current request on
these grounds would amount to selective enforcement. As with the
previous
issue, once the CABForum and Mozilla agree on a policy to be enforced
consistently, we will make the necessary adjustments.
Ryan Koski
Systems Engineer
GoDaddy.com, Inc.
Eddy Nigg
Thank you for your replies.
On 11/12/2010 09:58 PM, From Ryan Koski:
> Therefore, we feel it is appropriate to leave our CP/CPS as is,
> to cover the existing certificates in the field.
In that case you might have to find a different solution very soon
anyway since I believe that the current policy isn't sustainable.
> We appreciate that you have your own opinion on certificate lifetime
> maximums. However, the current Mozilla CA Policy does not have
> defined maximums.
Well, this item has been for a few years on the Problematic Practices
list and is currently scheduled to become official Mozilla CA Policy.
Please see:
https://wiki.mozilla.org/CA:Problematic_Practices#Long-lived_DV_certificates
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
> We understand that this issue is currently being
> debated in the CABForum, and once something formal is approved we
> will make the necessary adjustments.
Currently Mozilla nor Godaddy are bound to any such possible guidelines
and Mozilla has started its own procedures for updating its policy. Many
of the points addressed might be in parallel to the proposed guidelines,
which however hasn't been completed either and Mozilla might make a
decision different from the guidelines.
> Yes, the official wording of the current
> Mozilla CA policy is as you quote. However, there have certainly been
> root CAs that have successfully been admitted to the Mozilla Root
> program recently that also issue to non-qualified names and private IP
> addresses.
Right, the same like yours has been admitted in the past :-)
But this isn't the point and I believe that also this item is addressed
in both pointers from above (**). Since the update of the Mozilla CA
policy is fairly soon, in this case I'd propose to wait with the
inclusion of this CA root until completion of the latest update and make
a decision based on that.
Brian Smith
> > If Godaddy doesn't issue such certificates anymore it should update
> > the CPS accordingly. This obviously doesn't affect certificates
> > which were issued under a different policy.
>
> GoDaddy/Starfield do not use distinct policy OIDs to denote
> different certificate lifetimes. To do so would be problematic
> for several reasons, not the least of which are certificate rekeys
> which result in variable certificate lifetimes (but not exceeding
> a maximum duration). Our policy OIDs denote the level of
> vetting performed when issuing a given certificate as documented
> in our CP/CPS. Therefore, the comment that "This obviously doesn't
> affect certificates which were issued under a different policy" is
> incorrect. The certificates were all issued under the same policy
> to cover the existing certificates in the field.
Whether the CPS should change is one issue. But, the main issue is
this: Are you committing to a policy of never issuing certificates
valid for more than five years? Or, are you saying that now you
don't issue longer-lived certificates but you reserve the right to
do so in the future?
> We appreciate that you have your own opinion on certificate lifetime
> maximums. However, the current Mozilla CA Policy does not have
> defined maximums. We understand that this issue is currently being
> debated in the CABForum, and once something formal is approved we
> will make the necessary adjustments. For the purposes of our current
> root submission request, however, there is no official policy that
> governs certificate lifetimes. Therefore we believe this issue to be
> out of scope.
Then we should wait until the CAB Forum decision has been made and the
Mozilla CA policy are finalized before processing any more inclusion
requests. This is very poor time to have developers at Mozilla review
such requests anyway because we are all trying to focus on FF4.0,
and we will have a brand new, better, policy soon anyway.
> So while the policy has language that can be interpreted to be a ban
> on such practices, there is precedent from Mozilla that CAs who do
> issue such certificates will be admitted. To deny our current request
> on these grounds would amount to selective enforcement. As with the
> previous issue, once the CABForum and Mozilla agree on a policy to
> be enforced consistently, we will make the necessary adjustments.
We should just follow the policy. A change to a stricter policy is
not "selective enforcement." If we didn't follow the policy before
then that is a problem that we had in the past that hopefully we
can rectify. If the improvements to the policy and/or the enforcement
of the policy are not convenient, then let's just wait until the
new policy is in effect to avoid unnecessarily inconveniencing the
CAs.
Cheers,
Brian
Kathleen Wilson
Would one other person please review and comment on this request?
>>> ** CP/ CPS section 7.1.4: One to ten years after Certificate
>>> issuance
>> *** Comment: Our CPS permits up to 10 years. Indeed, we did issue
>> 10 year DV 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.
>
> Therefore, we feel it is appropriate to leave our CP/CPS as is,
> to cover the existing certificates in the field.
I think there should be an action item for Go Daddy to update their
CP/CPS to state that as of a certain date DV certificates are no longer
issued with validity longer than 5 years.
>> Additionally I believe that five years are a long period too.
>
> We appreciate that you have your own opinion on certificate
> lifetime maximums. However, the current Mozilla CA Policy
> does not have defined maximums.
As Eddy pointed out, this has been documented in our Problematic
Practices for a long time, and is now being seriously considered in the
updated Mozilla CA Cert Policy, which I hope to have ratified in early 2011.
See
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
“8. For a certificate to be used for SSL-enabled servers when only
domain verification is performed (e.g. DV), the certificate must not
have a validity longer than 27 months. In the case where the CA uses an
email challenge-response mechanism to validate that the certificate
subscriber has control of the requested domain, the CA must either use a
mail system address from the technical or administrative contact
information in the domain's WHOIS record, or one formed by prefacing the
requested domain with one of the following local parts: admin,
administrator, webmaster, hostmaster, or postmaster.”
When the updated policy is made official, CA’s will be given a certain
amount of time to comply with this in regards to the issuance of new certs.
I will note that I will need to follow up with Go Daddy on this.
However, I don’t think we should prevent Go Daddy from adding their
updated roots for this reason at this point.
>> Does Godaddy enforce a revalidation requirement after a certain
>> period?
>> Godaddy might be easily in the position to know about changes of
>> domain names holders.
Given the 5-year validity for DV certs, this question is quite relevant.
I would like a representative of Go Daddy to answer it.
> The issue of non-qualified hostnames and RFC1918 IP addresses is...
As Eddy mentioned, this has been documented on our wiki pages as a
Problematic Practice for a while now. It is an item that will be
discussed in regards to being added to the Mozilla CA Cert Policy next
year. It has not been our practice to deny root inclusion requests based
on this reason alone, but it has been our practice to understand how the
information is verified.
Kathleen
Ben Wilson
There seems to be a typo in the EV Policy OID for the Starfield Root Certificate Authority - G2 in the Certs Pending list (although in the information gathering document, it appears to be correct)--the Starfield CP/CPS says that the EV policy OID for GoDaddy.com Inc. is 2.16.840.1.114413.1.7.23.3 while the EV Policy OID for Starfield Technologies Inc. is 2.16.840.1.114414.1.7.23.3, so the latter number needs to replace the former for the Starfield G2 Root in the Certs Pending list. Also, GoDaddy.com, Inc. is the "O" in the Issuer field of the GoDaddy -G2 Root CA, so while it may be a non-issue, is GoDaddy a wholly owned subsidiary of Starfield Technologies, Inc. or vice versa because the CP/CPS, subscriber agreement, and relying party agreement are from Starfield? Somewhere that relationship ought to be made more clear. That's all I have.
Ben
-----Original Message-----
From: dev-security-policy-bounces+ben=digice...@lists.mozilla.org [mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On Behalf Of Kathleen Wilson
Sent: Tuesday, November 16, 2010 5:38 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Go Daddy Root Inclusion Request
Eddy, thank you for your thorough review of this request.
Would one other person please review and comment on this request?
>>> ** CP/ CPS section 7.1.4: One to ten years after Certificate
>>> issuance
>> *** Comment: Our CPS permits up to 10 years. Indeed, we did issue
>> 10 year DV 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.
>
> Therefore, we feel it is appropriate to leave our CP/CPS as is,
> to cover the existing certificates in the field.
I think there should be an action item for Go Daddy to update their
CP/CPS to state that as of a certain date DV certificates are no longer
issued with validity longer than 5 years.
>> Additionally I believe that five years are a long period too.
>
> We appreciate that you have your own opinion on certificate
> lifetime maximums. However, the current Mozilla CA Policy
> does not have defined maximums.
As Eddy pointed out, this has been documented in our Problematic
Practices for a long time, and is now being seriously considered in the
updated Mozilla CA Cert Policy, which I hope to have ratified in early 2011.
See
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
“8. For a certificate to be used for SSL-enabled servers when only
domain verification is performed (e.g. DV), the certificate must not
have a validity longer than 27 months. In the case where the CA uses an
email challenge-response mechanism to validate that the certificate
subscriber has control of the requested domain, the CA must either use a
mail system address from the technical or administrative contact
information in the domain's WHOIS record, or one formed by prefacing the
requested domain with one of the following local parts: admin,
administrator, webmaster, hostmaster, or postmaster.”
When the updated policy is made official, CA’s will be given a certain
amount of time to comply with this in regards to the issuance of new certs.
I will note that I will need to follow up with Go Daddy on this.
However, I don’t think we should prevent Go Daddy from adding their
updated roots for this reason at this point.
>> Does Godaddy enforce a revalidation requirement after a certain
>> period?
>> Godaddy might be easily in the position to know about changes of
>> domain names holders.
Given the 5-year validity for DV certs, this question is quite relevant.
I would like a representative of Go Daddy to answer it.
> The issue of non-qualified hostnames and RFC1918 IP addresses is...
As Eddy mentioned, this has been documented on our wiki pages as a
Problematic Practice for a while now. It is an item that will be
discussed in regards to being added to the Mozilla CA Cert Policy next
year. It has not been our practice to deny root inclusion requests based
on this reason alone, but it has been our practice to understand how the
information is verified.
Kathleen
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
David E. Ross
According to SlashDot, Go Daddy is soliciting bids for an outside party
to buy it. I think this request should be put on hold until that
transaction is completed and we can determine who is the new owner of Go
Daddy. After all, we need to have some confidence that the new owner
will continue to uphold the CP/CPS procedures that have been reviewed
for this request.
See
<http://tech.slashdot.org/story/10/09/11/1225207/GoDaddy-Up-For-Auction>.
--
David E. Ross
<http://www.rossde.com/>
On occasion, I might filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam from that source.
Kathleen Wilson
>
> According to SlashDot, Go Daddy is soliciting bids for an outside party
> to buy it. I think this request should be put on hold until that
> transaction is completed and we can determine who is the new owner of Go
> Daddy. After all, we need to have some confidence that the new owner
> will continue to uphold the CP/CPS procedures that have been reviewed
> for this request.
>
> See
> <http://tech.slashdot.org/story/10/09/11/1225207/GoDaddy-Up-For-Auction>.
>
I think it's worthwhile to keep an eye on the situation and make sure
that if an acquisition actually closes that proper care and precautions
are taken in regards to the roots included in NSS. Even if an
acquisition does go through, it could very well be the case that the
operation of the roots remains where it currently is, and with the same
people performing the jobs.
I plan to continue with this discussion of Go Daddy's request to refresh
their roots that are already in NSS.
Thanks,
Kathleen
Ryan Koski
> There seems to be a typo in the EV Policy OID for the Starfield Root Certificate Authority - G2 in the Certs Pending list
Thank you for pointing this out. I had not noticed that myself. I believe Kathleen has already corrected it.
> Also, GoDaddy.com, Inc. is the "O" in the Issuer field of the GoDaddy -G2 Root CA, so while it may be a non-issue, is GoDaddy a wholly owned subsidiary of Starfield Technologies, Inc. or vice versa because the CP/CPS, subscriber agreement, and relying party agreement are from Starfield? Somewhere that relationship ought to be made more clear. That's all I have.
GoDaddy.com, Inc. and Starfield Technologies, Inc. are both wholly-owned subsidiaries of The Go Daddy Group, Inc.
--
Ryan Koski
> I think there should be an action item for Go Daddy to update their CP/CPS to state that as of a certain date DV certificates are no longer issued with validity longer than 5 years.
We will add this statement in the appropriate place(s) in our CPS. However, we would obviously prefer to to wait until we had a complete list of concerns regarding our CPS so we can publish a single CPS update to address any/all of the concerns that arise as a part of this approval process.
> >> Does Godaddy enforce a revalidation requirement after a certain
> >> period?
> >> Godaddy might be easily in the position to know about changes of
> >> domain names holders.
>
> Given the 5-year validity for DV certs, this question is quite relevant. I would like a representative of Go Daddy to answer it.
Once we have issued a certificate to a particular FQDN, that FQDN becomes "locked" (in a sense) to that customer account. If a different customer account was used to request a certificate for the same name, the request is denied. The customer requesting the new certificate has to contact us to resolve the conflict. These conflicts are handled by our RA staff on a case-by-case basis. Typically if the new customer is able to prove domain control for the domain, we will make appropriate efforts to contact the existing customer to resolve the conflict. If we are unable to contact the existing customer, we most likely will revoke the original certificate and then allow the new customer to proceed with their request.
> As Eddy mentioned, this has been documented on our wiki pages as a Problematic Practice for a while now. It is an item that will be discussed in regards to being added to the Mozilla CA Cert Policy next year. It has not been our practice to deny root inclusion requests based on this reason alone, but it has been our practice to understand how the information is verified.
I'm not certain what you are looking for here ("understand how this information is verified"). We require the applicant to expressly acknowledge that they understand the request they are making is for a name or address which is not resolvable or routable on the public Internet. Beyond that, there is nothing that a CA, or anyone, can do regarding this.
--
Eddy Nigg
> Once we have issued a certificate to a particular FQDN, that FQDN becomes "locked" (in a sense) to that customer account. If a different customer account was used to request a certificate for the same name, the request is denied. The customer requesting the new certificate has to contact us to resolve the conflict. These conflicts are handled by our RA staff on a case-by-case basis. Typically if the new customer is able to prove domain control for the domain, we will make appropriate efforts to contact the existing customer to resolve the conflict. If we are unable to contact the existing customer, we most likely will revoke the original certificate and then allow the new customer to proceed with their request.
This makes sense - but how would you handle it for any party that didn't
buy their domain names with Godaddy either former or later? What about
those that are getting their next certificate from elsewhere? Wouldn't
that basically leave a previous domain name owner with a certificate
that it doesn't control or own anymore?
Ryan Koski
> According to SlashDot, Go Daddy is soliciting bids for an outside party
> to buy it. I think this request should be put on hold until that
> transaction is completed and we can determine who is the new owner of Go
> Daddy. After all, we need to have some confidence that the new owner
> will continue to uphold the CP/CPS procedures that have been reviewed
> for this request.
>
> See
> <http://tech.slashdot.org/story/10/09/11/1225207/GoDaddy-Up-For-Auction>.
Go Daddy does not comment on rumors. There is no transaction underway that would obstruct
Go Daddy's CP/CPS procedures and policies. There were media reports speculating about
Go Daddy being "up for auction." A few weeks later, a subsequent story was published by
The Wall Street Journal, reporting Go Daddy was not up for auction.
http://blogs.wsj.com/deals/2010/10/25/breaking-news-godaddycom-auction-is-scuttled/
Ryan Koski
> This makes sense - but how would you handle it for any party that didn't buy their domain names with Godaddy either former or later? What about those that are getting their next certificate from elsewhere? Wouldn't that basically leave a previous domain name owner with a certificate that it doesn't control or own anymore?
It doesn't necessarily matter where the domain is registered. The mechanism I described earlier works whether the domain is registered with Go Daddy or not. Obviously, if the domain is registered with Go Daddy then that provides an easier method of proving domain ownership/control. But there is no requirement that a domain be registered with us; our other processes for validating domain control will work in those cases.
In the case of a domain being transferred after a certificate has been issued, then conceivably the original subscriber would still be in possession of a certificate and private key, although this would be in violation of our Subscriber Agreement. I would submit that this issue affects all CAs and is not unique to Go Daddy, and that the validity period of the certificate is not really relevant to this issue. If a malicious actor were going to target a specific domain or FQDN, it seems highly unlikely that s/he will wait to launch the attack. There is too much risk that the value of the target could diminish over time that could make the attack ineffective. The attacker is likely going to launch the attack much sooner, while there is a known value in targeting the specific domain name.
Eddy Nigg
> In the case of a domain being transferred after a certificate has been issued, then conceivably the original subscriber would still be in possession of a certificate and private key, although this would be in violation of our Subscriber Agreement. I would submit that this issue affects all CAs and is not unique to Go Daddy, and that the validity period of the certificate is not really relevant to this issue.
Correct to the first part, but not to the second. The longer the
certificate is valid the higher the chance that the domain name will
change hands. For a popular name, the risk is higher obviously.
As a matter of fact we own a domain that belonged to somebody in S.
Korea. Considering that even today (years after we "purchased" the
domain name) this person might still be in the possession of a
certificate for our domain name simply doesn't give me a good feeling.
Hence the original question about re-validation of the domain control
after a certain period. In my opinion anything that goes beyond two
years should be re-validated.
Kathleen Wilson
> 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.
>
> Authority - G2” and “Starfield Root Certificate Authority - G2” roots.
>
Thank you to those of you who have reviewed and commented on this root
inclusion request from Go Daddy.
There are two action items that I plan to track in the bug.
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.
Note: There is also another action item that I am separating from this
root inclusion request… When the next version of the Mozilla CA Cert
Policy is ratified, adhere to the requirement of limiting the validity
of end-entity certs.
If there are no further comments on this request, I will close this
discussion and track the two action items in the bug. Once I confirm
that the two action items have been completed, I plan to recommend
approval of this request.
Thanks,
Kathleen
Kathleen Wilson
Thanks again to those of you who reviewed and commented on this request.
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.
These two action items will be tracked in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=527056
After I have confirmed that the action items have been satisfactorily
completed, I plan to recommend approval of Go Daddy's request 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.
All follow-up on this request should be posted directly in the bug.
Thanks,
Kathleen