Closed Bug 1151348 Opened 10 years ago Closed 10 years ago

GeoTrust and Ubiquitous CA Public Root program

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Version:
37 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: noloader, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:37.0) Gecko/20100101 Firefox/37.0 Build ID: 20150326190726 Steps to reproduce: I was looking at Google's Internet Authority G2 (https://pki.google.com). Its a subordinate CA (critical, CA:TRUE, pathlen:0). Its certified by GeoTrust Global CA. I understand the need to certify a subordinate for a company like Google (and other similar use cases). But I found it odd that GeoTrust did not place a name constraint on the domains that Google could issue. That is, I expected GeoTrust to limit the subordinate CA to Google's web properties. Name constraints are available with both the IETF and CA/B Forums. The relevant documents are RFC 5280, 4.2.1.10 Name Constraints and Baseline Requirements, 9.7 Technical Constraints in Subordinate CA Certificates via Name Constraints. This is a slightly different use case than a reseller acting as a subordinate. So the minor problem or the instance of the problem here is Google can mint certificates for any domain, and not just Google properties. It appears GeoTrust has a program that welcomes this sort of thing; see http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html. The program targets organizations and not traditional resellers whose responsibilities include varying levels of a well defined verification process. Mozilla includes GeoTrust Global CA in its trust store (https://wiki.mozilla.org/CA:IncludedCAs). That means Mozilla implicitly trusts any organization that is part of the Ubiquitous CA Public Root program. I'm not sure its wise to trust any organization to mint certificates for any property on the web. As I said earlier, this is a different use case than trusting a resellers whose responsibilities include a well defined verification process. It seems like a bad idea to me. Actual results: GeoTrust certified an organization to mint certificates for any domain AND Mozilla includes Geotrust in the trust store. Expected results: I'd expect GeoTrust to place name constraints on the subordinate CA participating in the program so an organization can only issue certificates for its web properties; and not mint certificates for any domain. If GeoTrust is not going to use name constraints, then I would expect Mozilla drop the trust relationship since there's too much potential for abuse from organizations.
The more I think about this, the less of a distinction I can make between the GeoTrust's Ubiquitous CA Public Root program and Trustwave (https://bugzilla.mozilla.org/show_bug.cgi?id=724929).
Component: Untriaged → Security: PSM
Product: Firefox → Core
Adding a couple folks from Symantec to the CC list. I would like to remind Symantec/GeoTrust about Mozilla's policy and the Baseline Requirements regarding all certificates that are capable of being used to issue new certificates, and which directly or transitively chain to a certificate included in Mozilla's CA Certificate Program. In particular, please see sections 8 through 10 of https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ and https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Frequently_Asked_Questions Regarding this article: http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html Does Symantec/GeoTrust plan to technically constrain (as per section 9 of Mozilla policy) this type of customer? If not, please keep in mind: "10. ... All certificates that are capable of being used to issue new certificates, that are not technically constrained, and that directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program MUST be audited in accordance with Mozilla’s CA Certificate Policy and MUST be publicly disclosed by the CA that has their certificate included in Mozilla’s CA Certificate Program. The CA with a certificate included in Mozilla’s CA Certificate Program MUST disclose this information before any such subordinate CA is allowed to issue certificates." Note that the disclosure of GeoTrust intermediate CAs is currently being tracked in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1019860 I did not find this Google cert in this list in that bug.
Kathleen, The press release Jeffrey linked is over 10 years old. There is nothing "new" here; merely an unfounded objection against sub-CAs that aren't technically constrained.
Ryan: is there an issue that GeoTrust has not listed "Google's Internet Authority G2" in its list of publicly disclosed non-constrained sub-CAs in bug 1019860? Gerv
Gerv: Yes, in as much as quite a few CAs failed to properly respond to the communication. Totally OK to reuse this bug for that, I did just want to highlight that the bug was filed on the premise that Mozilla should not allow unconstrained subCAs, and was itself based on decade-old news.
Sure; I agree the original filing is wrong in that Mozilla has no problem in principle with unconstrained sub-CAs. But in comment 2, Kathleen morphed the bug a little into the issue of appropriate disclosure. Will Google be prompting its CA to fix its disclosure? Gerv
I suggest we close this bug as WONT FIX or INVALID, then follow up in Bug 1019860. Note that just because I didn't find it listed in the bug or attachment, doesn't mean it's not there. I may have overlooked it.
(In reply to Ryan Sleevi from comment #3) > Kathleen, > > The press release Jeffrey linked is over 10 years old. The press release merely highlights the program targeting organizations. Its one thing when the terms are written by a lawyer and buried away in a CPS. Its another matter entirely when its written by a marketing department so a 13 year old can understand it. > ... merely an unfounded objection against sub-CAs that aren't > technically constrained. The loss of the independent 3rd party to validate signing requests is hardly unfounded. That means the organization makes the signing request and approves the signing request. The only thing unfounded is organization's desire or ability to mint certificates for all domains; and not just the web properties it owns or controls. I'm not really sure what to say if you don't see the incumbent problems with that. Why would an organization object to being name constrained to its own web properties? What is so offensive about using a name constraint to enforce policy? Here, the name constraint is equivalent to the auditor and the security controls in they system are restored.
(In reply to Gervase Markham [:gerv] from comment #6) > I agree the original filing is wrong... I think the underlying problem of the loss of the independent third party auditor that validates signing requests is still unaddressed. That is, what happened to the CA/RA and the separation of concerns? (And some might say Mozilla's policy is wrong ;) > that Mozilla has no problem in > principle with unconstrained sub-CAs. But in comment 2, Kathleen morphed the > bug a little into the issue of appropriate disclosure. Katleen/Gerv - do you mind if I file another report asking for a policy change in the Inclusion Policy (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/)? The new report can provide the opportunity to answer a few open questions. I'd like to hear why organizations feel they need or opportunity to mint certificates for all domains; and not just the ones they own or manage. I'm also interested in why Mozillia feels its OK for organizations to mint certificates for all domains; and not just the ones they own or manage. And folks like Ryan can explain why concerns over these thing are "unfounded" or "unreasonable". I'm sure others would like to know, too. Related to Gerv's statement of "Mozilla has no problem in principle with unconstrained sub-CAs," I'd also like to know why Mozilla is accepting "trust" when a security control can be placed to enforce the policy. "Trust" is something we use when we have no security controls to place, so I'm a little curious with the position. Plus, some of the stuff in the Inclusion Policy is outdated or does not reflect the direction in which things are moving. For example, IP addresses are scorned by some of the latest standards (like HSTS (RFC 6797, Appendix A) and HPKP (https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21)), so it may be an opportunity revise some text. (I don't claim IP addresses should be removed; just that the handling of them is changing and it might be a good idea to reflect it in a few places).
(In reply to Jeffrey Walton from comment #8) > The press release merely highlights the program targeting organizations. Its > one thing when the terms are written by a lawyer and buried away in a CPS. > Its another matter entirely when its written by a marketing department so a > 13 year old can understand it. Jeffrey, you'll find Mozilla's policy and CA communications are very aware of this, and have long since incorporated this practice as part of the discussions related to CA practices. I highlight its age because there is truly no new information being presented. You can examine the discussions for Mozilla's CA Inclusion Policy, v2.1, to see the surrounding discussion about unconstrained intermediates. > The loss of the independent 3rd party to validate signing requests is hardly > unfounded. That means the organization makes the signing request and > approves the signing request. This is fundamentally no different than an RA. Again, Mozilla's policy has long accounted for this practice as part of the discussion of what CAs do and are expected to do. > Why would an organization object to being name constrained to its own web > properties? What is so offensive about using a name constraint to enforce > policy? Here, the name constraint is equivalent to the auditor and the > security controls in they system are restored. This has been discussed extensively on mozilla.dev.security.policy. I would encourage you that if you feel that all organizationally-distinct subCAs should be technically constrained, Bugzilla is not the right place for that discussion. However, before posting, I would encourage you to read the (many) past discussions of this, via https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/name$20constraints You will find that, as best I can discern from this bug, the answers to your question have already (and repeatedly) been provided. You will find multiple discussions of the Mozilla inclusion policy 2.1 update, including a discussion of why technical constraints are insufficient.
(In reply to Ryan Sleevi from comment #10) > (In reply to Jeffrey Walton from comment #8) > > The loss of the independent 3rd party to validate signing requests is hardly > > unfounded. That means the organization makes the signing request and > > approves the signing request. > > This is fundamentally no different than an RA. Actually, it is. First, there's a reason for auditor independence and separation of concerns, and there's a reason its fundamental to systems and institutions in a number of verticals (and not just public key certificates). That's a fundamental problem that cannot be dismissed as "unfounded". Browsers can choose to do nothing, but the problem still exists. Second, the "Enterprise certificates" are not limited to an organization's internal operations. They surface in the outside would. In some cases, they surface in the outside world by design. For what its worth, I have no problem with the ability for an organization to issue its own certificates. I understand the need and know its a expedient way to accomplish goals and fulfill requirements. I have a problem that they are not either (1) validated by a third party or (2) name constrained. Pick either one to restore balance.
(In reply to Jeffrey Walton from comment #11) > Actually, it is. Hi Jeffrey, Again, bugzilla isn't the best place for this, but no, it's not. I realize this is a game of "he said/she said", but as a practical matter, it isn't. Again, however, Bugzilla is not the place for this discussion. Even policy changes are best discussed not on Bugzilla, but on mozilla.dev.security.policy. > Second, the "Enterprise certificates" are not limited to an organization's > internal operations. They surface in the outside would. In some cases, they > surface in the outside world by design. Yes, and Mozilla has long been aware of this, recognize it, and taken appropriate steps to curtail it. While I realize these steps may not be in line with your desires, they have been fairly extensively discussed - on mozilla.dev.security.policy. > For what its worth, I have no problem with the ability for an organization > to issue its own certificates. I understand the need and know its a > expedient way to accomplish goals and fulfill requirements. I have a problem > that they are not either (1) validated by a third party or (2) name > constrained. Pick either one to restore balance. Thanks for your input. You may wish to share this on mozilla.dev.security.policy. Since it seems you may not have had the opportunity to read the past discussions (or, if you have, may have missed the nuance due to the speed of reading), it's worth noting that such organizational sub-CAs are required to adhere to the same policies as the root CAs, with one exception. These sub-CAs are not required to go through a public review/discussion process, but in return, the issuing root CA runs the risk of having its certificate removed if the sub-CA fails to adhere to the root CA's policies or the public's expectations. I'm going to mark this Resolved/Invalid, not because the discussion is fundamentally invalid (you're certainly entitled to your opinion on the matter), but because it's the wrong venue for the discussion. I know I sound like a broken record, but mozilla.dev.security.policy is where this conversation should happen. As Kathleen notes in Comment 7, the matter of Geotrust disclosure can and should happen elsewhere as well.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Here's a related request: "Please assign/require an OID for server certificates issued by a non-constrained subordinate CA," https://bugzilla.mozilla.org/show_bug.cgi?id=1152017. The first step in handling these certificates properly is identifying them. Currently, we can't do that.
(In reply to Ryan Sleevi from comment #12) > it's worth noting that such organizational sub-CAs are required to > adhere to the same policies as the root CAs, with one exception. These > sub-CAs are not required to go through a public review/discussion process, > but in return, the issuing root CA runs the risk of having its certificate > removed if the sub-CA fails to adhere to the root CA's policies or the > public's expectations. We know that's not useful in practice. TÜRKTRUST is an example of a failure to hold a CA responsible for their RAs. Trustwave is a similar example of not holding a CA responsible for its policy violations. Should something happen with a company like Verisign or GeoTrust in the future, nothing [effective] will be done. We all know it. Its not a secret. In the absence of responsibility and accountability, we need security controls to enforce the policies.
(In reply to Jeffrey Walton from comment #14) > We know that's not useful in practice. TÜRKTRUST is an example of a failure > to hold a CA responsible for their RAs. Factually untrue. Please take this discussion to mozilla.dev.security.policy. This is the final time I'll respond on the bug. There is a venue for these discussions. It's not Bugzilla. This isn't trying to squelch discussion. It's trying to help you make your voice heard, rather than get written off.
(In reply to Ryan Sleevi from comment #15) > (In reply to Jeffrey Walton from comment #14) > > We know that's not useful in practice. TÜRKTRUST is an example of a failure > > to hold a CA responsible for their RAs. > > Factually untrue. > > Please take this discussion to mozilla.dev.security.policy. This is the > final time I'll respond on the bug. There is a venue for these discussions. > It's not Bugzilla. This isn't trying to squelch discussion. It's trying to > help you make your voice heard, rather than get written off. Ryan - the reason this is in the Bug Reporter is because it can be cited as Mozilla either taking action or not taking action. This creates an actionable item (unlike endless discussions or debates). The discussions have already been had, and the decisions have already been made. Folks like me are already written off. Where we say it makes no difference.
(In reply to Jeffrey Walton from comment #9) > I think the underlying problem of the loss of the independent third party > auditor that validates signing requests is still unaddressed. That is, what > happened to the CA/RA and the separation of concerns? > > (And some might say Mozilla's policy is wrong ;) When an embedded CA issues certificates, there is no independent third party validating the requests. Why do we think this is OK? Because the CA has the necessary audits and security controls in place to make sure there is no misissuance. When an enterprise CA such as the one we are discussing issues certificates, there is no independent third party validating the requests. Why do we think this is OK? Because the CA has the necessary audits and security controls in place to make sure there is no misissuance. > Katleen/Gerv - do you mind if I file another report asking for a policy > change in the Inclusion Policy > (https://www.mozilla.org/en-US/about/governance/policies/security-group/ > certs/policy/inclusion/)? It is extremely unlikely that Mozilla policy will be updated to ban enterprise PKI of this sort. > The new report can provide the opportunity to answer a few open questions. > I'd like to hear why organizations feel they need or opportunity to mint > certificates for all domains; and not just the ones they own or manage. Because for large enterprises, the number of domains concerned is large and changes on a monthly basis. Managing this with name constraints is simply not practical. > Folks like me are already written off. Where we say it makes no difference. Victimhood does not become you. What you see is us disagreeing with you, not us ignoring you. Gerv
(In reply to Gervase Markham [:gerv] from comment #17) > (In reply to Jeffrey Walton from comment #9) > >... > It is extremely unlikely that Mozilla policy will be updated to ban > enterprise PKI of this sort. No one is asking to ban Enterprise PKIs. We are asking that the certificates be constrained to compensate for the loss of the independent third party that traditionally validates the request. The constraints have been available for years. The constraints also indirectly compensate for the loss of responsibility and accountability in the system, and do so without prejudice. Face it: nothing can be done after the fact with the large CAs because it would affect too many users. > > The new report can provide the opportunity to answer a few open questions. > > I'd like to hear why organizations feel they need or opportunity to mint > > certificates for all domains; and not just the ones they own or manage. > > Because for large enterprises, the number of domains concerned is large and > changes on a monthly basis. Managing this with name constraints is simply > not practical. So I'm clear: what kind of numbers are you speaking of? The system lacks requirements for reporting this sort of stuff, so I'm not sure where the line of practicality lies or how far beyond it the task lies. Otherwise, it sounds like the argument reduces to "its too inconvenient to do it right" or "its too much work to do it right". Internships at enterprise companies such as those that would be affected are prestigious.
(In reply to Jeffrey Walton from comment #18) > (In reply to Gervase Markham [:gerv] from comment #17) > > (In reply to Jeffrey Walton from comment #9) > > >... > > It is extremely unlikely that Mozilla policy will be updated to ban > > enterprise PKI of this sort. > > No one is asking to ban Enterprise PKIs. Given the usual definition of Enterprise PKI, you are. Name constrained intermediates are not Enterprise PKI. > We are asking that the certificates be constrained to compensate for the > loss of the independent third party that traditionally validates the > request. The constraints have been available for years. Actually, near-ubiquity of name constraint checking is a fairly recent thing. And I believe that, even now, Safari doesn't check them. > The constraints also indirectly compensate for the loss of responsibility > and accountability in the system, and do so without prejudice. Face it: > nothing can be done after the fact with the large CAs because it would > affect too many users. Except that the measures we put in place for CNNIC could be put in place for any CA. > > Because for large enterprises, the number of domains concerned is large and > > changes on a monthly basis. Managing this with name constraints is simply > > not practical. > > So I'm clear: what kind of numbers are you speaking of? Ask an enterprise with an intermediate. > Otherwise, it sounds like the argument reduces to "its too inconvenient to > do it right" or "its too much work to do it right". No, because we disagree on the definition of "right". Gerv
You need to log in before you can comment on or make changes to this bug.