They aren't MITM certificates, they are cross-signs for enterprise deployments. If you run a large enterprise you might have lots of foo.corp.example.com and bar.corp.example.com hosts. A cross-sign would allow you to issue certs for these names that would be trusted by default.
It may also give you the power to issue certificates for any name or, hopefully, it will be name constrained([1]). That's up to the CA however. The CA is taking on responsibility for all certificates issued under these cross-signs when they do this. Mozilla is currently in the process of requiring that these enterprise certificates either be name constrained, or be audited at the same level as roots.
"MITM certificates" are those used for the purpose of intercepting secure traffic. Many organisations have the certificates to do that, but are under audits, and technical and legal constraints not to.
That's very different from, say, TrustWave, who issued such a certificate with full knowledge of what it would be used for.
I agree that this isn't the best of situations. Certificate Transparency is the best answer that we have, but it's going to take a while to deploy.
I think it would be more accurate to say a "MITM certificate" is any private key with the ability to impersonate server and intercept SSL/TLS traffic.
There's a huge difference in security between a cryptographic-strength guarantee enforced by reliable technical mechanisms and the security provided by a civil law contract enforced by an audit regime. Also, note that the world's true Relying Parties (i.e., every web user and server operator who could potentially be MITM'd by this private key) are usually not formally acknowledged as parties to these contracts and as such have no say in their creation or even knowledge of their existence.
It's a question of terminology, but when groups like Chrome Security, Mozilla etc talk about MITM certificates and that they are forbidden, we mean those that are used for intercepting traffic.
I think this is a case where the precise terminology is critical.
The only way to know how a certificate may or may not "be used" is by looking at how the source code of all client applications to see how they will interpret it.
How many of the cases of trusted-root chained MITM seen in the wild (Iran, Turkey) were prevented by the business agreements making MITM "forbidden"?
But - is there anything inside these certificates that identify to a browser what the "intended purpose" of a given certificate is, and prevents such a CA from being used for MITM attacks? How would a regular browser such as IE or Safari act when presented with a certificate for "bank.example.com" signed by such a CA?
Yes: the X.509 nameConstraints field, which modern browsers will read to determine which subdomains are acceptable as subjects for certs signed by the CA.
Earlier today I thought that nameConstraints was ineffective, but it seems to turn out that the problem is mostly limited to Safari.
For us we require CAs that are not technically constrained to be independently audited to WebTrust for CA requirements, Moving forward thanks to Mozillas new policy the same will be true for all CAs.
Thanks for the clarification. On a related note do you understand where the X.509 Name Constraints effort sits? Which, if any, browsers implement it? If it's not 100%, do you know why browsers are hesitant to deploy it?
Name Constraints support is pretty good in modern certificate libraries. It's certainly in CryptoAPI these days which accounts for the bulk of users.
But there are two ways to use Name Constraints: they can be marked critical or non-critical.
Critical Name Constraints are great, but they will cause anything that doesn't support Name Constraints to reject the certificate. This is obviously a problem because few deployments have much control over their client base.
Non-critical name constraints provide a security benefit to clients that support them without affecting those that do not. Clients that don't support them are vulnerable to misuse of the constrained certificate, of course, but since the alternative is often an unconstrained, CA certificate, it's still a clear win.
I'm not sure, but in the back of my mind I don't think that it does. I've agreed to write about this stuff for the Web PKI Working Group so I'll need to do a survey of the various capabilities at some point.
Since this comment is pegged to the top of the thread and is strictly inferior to the 'agl comment below it, I think you should downvote this one and upvote his.
I feel like I have to be misunderstanding something about this page and the attached data sheet, because it seems to be promoting a service that directly contravenes Mozilla's policies: you're not allowed to use CA=YES certificates to enable enterprise MITM tools.
Furthermore, minting certificates for a large and growing number of popular web properties --- which is something you end up doing almost immediately when you set up enterprise web proxies --- is a good way to get noticed by Google's SSL/TLS team and shitcanned from Chrome. That's a consequence of Google's certificate pinning regime, which operates incidentally as a kind of surveillance network for certificate forgery.
First off so there is no ambiguity let me say clearly that GlobalSign's policies do not allow the use of certificates that chain to our roots to be used for MiTM purposes (or other malicious use cases for that matter).
That said there are lots of reasons why a company might want or need to operate their own in house PKI and have that PKI trusted; one easy to understand case is google; though they are not our customer they operate their own in house PKI that they use to issue the many many SSL certificates their infrastructure utilizes:
https://sslcheck.x509labs.com/en_US/sslcheck?host=www.google...
But SSL is not the only reason one might want to operate their own internal PKI that is trusted, other cases include business to consumer and business to business communication (for example S/MIME).
As for how we (and other CAs) go about ensuring trusted root deployments are not used for MiTM cases, there is the obvious contractual obligations that are accompanied by audits but we also were the first publicly trusted CA to use Name Constraints to deploy qualified subordination to these deployments (which has become a requirement now – it was not when we started).
This approach technically limits what domains these enterprise trusted root customers are trusted by mainstream clients for - see: http://unmitigatedrisk.com/?p=24
There are also a set of “Trusted Root” customers who are in the process of becoming trusted by browsers (which can take 3-5 years) where we will cross-certify their root enabling them to be trusted while their own key material becomes ubiquitously trusted.
I should also add that Mozila’s root inclusion policy (as well as Microsoft’s and the other root programs) allow for these scenarios.
I hope this helps clarify, please let me now if you have any questions.
Ryan Hurst
CTO, GlobalSign
ryan.hurst@globalsign.com
Hey, Ryan. Thanks for clarifying. I only have one followup question.
Do any of your offerings provide customers with custody of an X.509 certificate that chains to a GlobalSign certificate that is trusted by any of IE, Mozilla, Chrome, or Safari where that X.509 certificate has CA:TRUE in its Basic Constraints?
By "custody" I mean that the private key corresponding to that certificate is held in some fashion on customer premises, regardless of the technical controls implemented in the device in which it's held.
They do and that's is specifically what this offering is about.
However our policies have always been that those entities need to meet the same requirements (operationally, etc) as we do which includes not participating MiTMs with any key material associated with that PKI.
Those customers who do have such CAs are also (normally) subject contractual restrictions to what namespaces they can issue against and they are always subject to audits where we confirm their usage is consistent with those policies.
In the very rare cases where that is not the case they are audited to meet the exact requirements we meet - we almost never do this.
It’s a difficult problem as a whole, there are legitimate use cases that help secure the web and enable commerce that are best served by having publicly trusted certificates our goal as an industry is to find ways to address those needs while reducing the risk.
To that end when I joined GlobalSign a year ago (from Microsoft) one of the first things I did was started here to advocate the industries use of name constraints as a means to reduce risk for all parties involved in these scenarios.
Thanks. I'm sorry, I knew MITM wasn't the only or most common reason enterprises wanted these certs, but wrote lazily.
Are the nameConstraints extensions on these certs marked critical? I didn't know they could even be non-critical (one RFC says they can't) but 'agl says otherwise and would know.
That's the position we start with when we engage with a customer but its dependent on the community in which they are going to communicate with. To be honest in most cases today (due to Safari) criticality is not enabled on most deployments.
The only browsers you can MITM are Safari and Opera, yes. Stuff like https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-... would be worrisome enough without people creating certificates that, according to anyone's best reading of the standards at the time the software was written, should be globally accepted CA's.
I think that to a first approximation CA trust only matters for browsers, because non-browser applications have a whole panoply of other mechanisms that they should already be using to ensure the authenticity of SSL certificates. To put it differently: people running non-browser applications tend to have more control of their destiny.
It's interesting that we bring this up, because it makes me now think that maybe the best way to jumpstart TACK is to implement it as a library that IOS programs can use.
I should probably add that the requirements that those customers have to meet go far beyond storage of the key material on a HSM (re: technical controls implemented in the device in which it's held).
There is a basic concern about "nuclear proliferation" of X.509 CA=YES certificates, since it is unlikely that any medium-sized collection of enterprise networks can among themselves safeguard the entire equivalently-sized set of corresponding certificates. Enterprise internal network security is surprisingly and creatively bad.
That said, if we're (a) in a universe where critical:true nameConstraints are enforced on the last couple versions of Safari, Chrome, Firefox and IE, and (b) you're only issuing critical:true nameConstraints certificates, it probably isn't worth being alarmist here.
In any case, thank you for commenting here. I had hoped to have a chance for once to join my fellow HN commenters in a rousing game of baying at the moon over the injustice of it all, but instead find myself amidst a carnival of X.509 learning. Hooray?
I totally understand the concern and I think the CA industry as a whole does as well.
Moving forward Name Constraints will be adopted (finally) which is a good thing. Today it is supported by the majority of devices on the internet and given how fast browsers update now it wont be too long until the extension can be marked critical.
What certificate lifetimes are on these CA certificates you're issuing without critical name constraints?
Will you reissue them all (for free) once you decide to start marking new ones critical? Will you require all such entities get reissued certs? Can you contractually require that they destroy the old certificates?
Then there's the matter of how problematic OCSP is; even if you revoke the old ones, it may not matter.
Lifetime varies, but yes the goal is to re-issue them once criticality is viable -- customers are contractually obligated to support that migration also.
Said migration would ave no cost from us on the customer, I can't speak to what the other CAs do.
Can you expand further on the practicality of the Name Constraints extension? My understanding is that not all browsers/libraries enforce them and IIRC, that certs that use them may not work in some browsers?
(Copying this reply of mine from another part of the thread as you're not the only person to ask.)
Name Constraints support is pretty good in modern certificate libraries. It's certainly in CryptoAPI these days which accounts for the bulk of users.
But there are two ways to use Name Constraints: they can be marked critical or non-critical.
Critical Name Constraints are great, but they will cause anything that doesn't support Name Constraints to reject the certificate. This is obviously a problem because few deployments have much control over their client base.
Non-critical name constraints provide a security benefit to clients that support them without affecting those that do not. Clients that don't support them are vulnerable to misuse of the constrained certificate, of course, but since the alternative is often an unconstrained, CA certificate, it's still a clear win.
Non-critical name constraints provide a security benefit to clients that support them without affecting those that do not.
The sole raison d'être for the entire CA infrastructure is to prevent active MITM-style attacks. So from that perspective what you said is positively Orwellian.
Noncritical name constraints absolutely do affect clients that don't support them. It reduces their security by making them vulnerable to MitM!
The entire purpose of the critical flag was to allow evolving the PKI system without reducing security for existing systems. We ought not set the flag FALSE because the CA's big customers prefer flexibility to the security of the whole ecosystem.
Clients that don't support them are vulnerable to misuse of the constrained certificate, of course, but since the alternative is often an unconstrained, CA certificate, it's still a clear win.
A false dichotomy being imposed by a well-funded minority for which it serves their interests.
non-critical name extensions strictly dominate unconstrained certificates
Don't you see how, once again, the CA industry has shifted the debate from the level of security everyone expected them to provide all along to another lesser of two evils?
The discussion isn't about whether or not we must require name constraints on 3rd-party sub-CAs to be marked 'critical'. The issue is that the world of SSL/TLS client application users and developers believe, expect, and rely upon the non-proliferation of private keys with the ability to forge identities for the servers to which they connect.
Oh look, I have deep admiration for AGL. I like RMH too! I agree that they are "good guys".
But this is not about the the person or the corporation. It's about the users of PKI and the massive existing code infrastructure (not just browsers) they rely upon today and the attacks to which our systems may or may not be vulnerable under the different CA issuance policies.
RFC 5280: 4.2.1.10. Name Constraints: Conforming CAs MUST mark this extension as critical
Sure, there are times when bending the rules of an RFC may be the right thing to do. But breaking this rule violates an interface contract critical for security, thereby retro-actively reducing the security of conformant implementations.
Therefore, users and developers of existing security products must oppose this violation of RFCs.
You keep citing the RFC as if it mattered. What matters in reality are the judgements of Microsoft, Google, Mozilla, and Apple (the HTTPS cabal). That this is annoying does not change its underlying truth.
Of those four organizations, I feel like I could make a strong argument that Google is the one with the best activist stance on improving Internet privacy, the one doing the most to improve the core HTTPS infrastructure.
The RFC you're citing is the product of a bunch of people sitting in a room talking. RFC policies do not bind organizations. About the most you can say about them is that they mean the HTTPS cabal is using something other than HTTPS. Ok, but that is the mother of all [sp]e[md]antic arguments. (Can we use "spemdantic" from now on?)
Oh, I hold no illusion of the infallability of the IETF process!
But at the end of the day the world needs to have secure SSL/TLS applications. This requires it to be possible for "one skilled in the art" to be able to design and implement an application using this protocol. He must be able to understand the stated and implied requirements for security in order to have any chance of producing a secure application. And a secure application needs not just to interoperate well, but it must also refuse to interoperate insecurely, prevent impersonation, and so on.
So if we can't end up with secure applications by writing them to the RFCs, then what the hell do we write them to?
Where is this document defining all the ways in which CAs now and in the future feel free to relax the identity constraints which rely upon them to provide?
If it is not possible for a competent and conscientious software developer to write a client application from existing documentation, rely upon a set of root CAs, and end up with a countably finite and well-bounded number of private keys in existence that can impersonate legitimate servers to his application then the CA system has failed in its one and only mission.
The point is that writing them to the RFC would not make them secure. The alternative to non-critical nameConstraints is no nameConstraints, which is RFC-acceptable. You're just wrong here, Marsh.
Selling widely-trusted sub-CAs to 3rd parties, with or without name constraints, does absolutely nothing to make HTTPS more secure for me or the vast majority of relying users.
Nevertheless, if you want to sell sub-CAs with critical name constraints to 3rd parties from your widely-trusted root, fine. That's been a defined feature of PKI for a long time.
If you want to sell sub-CAs with noncritical name constraints to 3rd parties, that's fine too. Just do it from a different set of roots than the ones that we all agreed to rely upon, precisely because we had our expectations set that they would not do that sort of thing.
Who's "we"? The people who need to agree about this --- the HTTPS cabal --- have already accepted non-critical name constraints. If you disagree with them, remove GlobalTrust from your CA store.
"We" are consumers who rely upon HTTPS to protect our $50 liability limited credit card transactions.
"We" are citizens living in repressive regimes who rely upon HTTPS to protect our emails arranging our family's emigration and escape from persecution.
"We" are software developers relying on HTTPS to secure our connections to Github to prevent attackers from inserting backdoors in our codebase.
"We" are the servers who rely upon the HTTPS client to do a thorough job of proving the absence of an active attacker on the network between us.
That's a rousing speech, but, again, and to a first approximation, there's only 4 organizations in the world who need to agree on TLS PKI policy. You work for one of them, don't you? Go yell at them.
Yeah I didn't mean for it to sound all rousing like that, it just came out that way.
You're probably correct in that "4 organizations in the world need to agree on TLS PKI policy", but that doesn't make it a good thing. The problem is that these N ~= 4 organizations tend to not see themselves as directly bearing the risk of a security failure in the trusted root program. The true Relying Parties are greatly underrepresented in this discussion.
I see people from many of these orgs here in this HN discussion. And, yeah, you can count on some folks getting an earful as soon as the occasion arises.
For anyone coming to RSA 2013 San Fransisco we'll be having an SSL/TLS panel discussion. This topic seems likely to come up.
I of course feel a little singled out here but as has been called out by Adam many (if not all) trusted roots have this same offering.
It is allowed by all the root programs.
The practices (both technological and procedural) we put around our program are some of the best in the industry, we take this responsibility very seriously.
More over we very rarely do it and instead work with customers to utilize our managed PKI offerings where we operate the infrastructure on behalf of the customer.
many (if not all) trusted roots have this same offering
Really? Care to name names?
If this is so common, allowed, and totally above-board, why is the industry being so secretive about it?
Why won't the CA industry disclose even the number of sub-CA (constrained critically, noncritically, or not at all) private keys in possession of 3rd parties (HSMs or no)?
Those projects show sub-CAs actually seen in public scans. They don't show all the sub-CA certs that could be used to compromise one's own security. We don't even have any idea what percentage of sub-CAs they show. For example, I doubt they show the TURKTRUST sub-CA that was used in an actual MitM of Google (and likely many others).
This is not directed specifically at you @rmhrisk, but it's really disappointing how everyone involved in PKI seems to have a systematic habit of pretending like clearly identified potential risks and vulnerabilities are equivalent to impossible until (and sometimes even after) they're actually caught being used in an actual exploit.
Marsh, I understand your concern and I share it though I don't agree with the conclusion (re sticking head in the ground).
With that said GlobalSign has committed to implementing CT and we hope all other CAs agree to do the same as Adam points out earlier in this thread its the way to bring the desired transperancy.
That said it alone inst enough either, to start we also need TACK (and/or HSTS pinning), CAA, robust revocation checking and Name Constraints.
And while conversations like this are uncomfortable (certainly for me being on the receiving end) I think they help too.
The RFC may or not matter, but what does matter is doing the right thing. For example, if critical Name Constraints are not universally supported, does that make it right to use the non-critical ones? I don't think so.
If Name Constraints are indeed important, I'd much rather see the CAB Forum first work with Apple until support is universal (or reasonably-well supported; whatever that means), and then start to use them.
Careful: two different arguments here. One is what Google is doing, the other is what GlobalTrust is doing.
While I'm not alarmed by what GlobalTrust is doing, I think CA's should not be in the business of selling CA=YES certificates to other organizations. No matter what X.509 allows them to express.
Let me rephrase the question: if Name Constraints are used and the extension is marked as critical (as 5280 requires), do you know (or can estimate or guess) what percentage of public users will not trust the certificate?
Doing so right now would mean that apple users could not visit google.com or microsoft.com both of which who operate sub-cas chained to public roots.
Deploying non-critical name constraints to the existing community of subcas reduces the risk for everyone and gives apple time to fix their aged tls / certificate stack.
So why can't Google get a cert for google.com from a trusted root CA like everybody else?
What economic benefit does it provide that outweighs the reduction in security experienced by users of Safari and countless other non-browser clients by allowing Google to be in possession of a private key that can impersonate the identities of arbitrary TLS servers?
If all of Google's properties were issued certs directly from Equifax rather than their own CA, the Internet security situation would change not- one- bit.
Beyond that, Google operates one of the four most important clearinghouses of Internet trust by managing the Chrome certificate policy. It's a little silly to suggest they're pulling a fast one on the Internet; if you don't trust them, you have bigger problems than nameConstraints.
Google is a terrible example for discussion here because, as you point out, they also ship a popular browser and are actively contributing positively to PKI security in several ways.
Perhaps if you were to mentally s/Google/that hospitality company customer of Trustwave/ perhaps you could see my point more clearly.
I was replying to the specific scenario given by RMH "apple users could not visit google.com".
RMH chose Google. For him, it was a brilliant rhetorical strategy :-)
So who would be a good example of an organization possessing a 3rd party sub-CA for me to advance my argument? It's much harder because most of them are already relied upon in other critical ways, or are kept secret under confidentiality.
"That hospitality company issued a sub-CA by Trustwave" is the best I can come up with at the moment.
Yeah, I'm reading this the same way you are. I guess Monday is going to be another fun day at the office.
Edit: Apparently this is the enterprise cross-signing use case. So, ideally they're using name constraints and their issuing policy would need to comply with the browser and OS root CA policies.
You sound ruefully sarcastic but I have to say that the prospect of a week of political and logistical wrangling to get the most powerful tech company in the world to stomp mightily onto the forehead of a rogue SSL CA would absolutely get me out of bed bright and eager. I sort of envy you!
Well, I rarely have to deal with these things directly because it mostly falls to Langley and Palmer. But anything involving the CAs always feels like far more work than it really should be. Both Mozilla and Chrome have root certificate inclusion policies that clearly outlaw this kind of behavior (assuming I'm reading correctly), but the CAs have operated for so long without any transparency that many of them are less than consistent on compliance. So, when we find violations we make them fix it, but it's a painful process because the mess is usually bigger than it appears on the surface, and you don't want to break all the innocent sites that are relying on the CA.
That said, I feel like our team and Mozilla's are making some real progress here on a path toward a far more transparent and reliable CA system. And things like pinning and reporting are useful both as stopgaps and longterm tools for more security conscious site operators.
> for issuing SSL Certificates for their own domains
If you can only issue certificates for your domains and subdomains, then it's not an issue. This sounds more like an alternative to setting up a Windows Enterprise CA and then distributing the root cert to all of your non-Windows clients.
e: Think of it like this: instead of just giving you a wildcard cert, they're letting you make individual certs for your subdomains yourself.
There is no mechanism in the TLS X.509 PKI that enforces that rule. If a product promises transparent trust for any sort of customer-selected domains, it is either lying or selling the cryptographic equivalent of plutonium.
There have definitely been attempts to build products that use technical controls in the CA product to enforce the restrictions --- ie, the customer gets a locked down box that tries to make sure it isn't misused --- but as I understand it, these are no longer OK to sell.
> A FIPS 140-2 Level 2 compliant device to generate and managing your root certificate keys.
For those not versed in this particular jargon: "FIPS 140-2 Level 2" pretty much means "tamper-evident seal" (part of a sticker over the opening stays on the box when you try to remove it - this is only slightly more secure than I make it sound.) Note also that this does not appear to include any restriction on the computers which can say "please sign this certificate for me". Sensible CAs will have extensive physical security around such devices, but can we count on anyone with $BIGNUM dollars to get this right?
On a cryptographic level, there is the paper discussed at http://blog.cryptographyengineering.com/2012/06/bad-couple-o... (http://hal.inria.fr/docs/00/70/47/90/PDF/RR-7944.pdf), which totally pwns some well-regarded smart cards using a (really nifty improvement on) a years-old crypto attack, then goes on to note that the authors really wanted to try their hand at a couple of HSMs too but lacked the funds. Which doesn't prove anything about HSMs, but doesn't exactly give one a lot of confidence either.
So yeah, they do seem to be handing out the keys and hoping that auditing/policies/insurance covers it.
Strictly speaking, the mechanism is there (Name Constraints, see section 4.2.1.10 in the RFC 5280), but it's not practical due to it not being implemented consistently across all major browsers.
EDIT: Changed RFC number from 2459 (obsolete) to 5280.
No, you're right Ptacek because in this case the extension is being marked NON-critical. I.e., if the client code doesn't recognize the name constraint extension, it's OK to just ignore it.
You're forgetting the huge mass of non-browser SSL/TLS clients.
Do you see the expressions of surprise about this policy here on HN? These are the world's more informed client application developers.
Consider now that your home router's firmware update client, your server's IPMI, and the entire global network for real-time trading of [strategic material] was written by developers to RFCs that told them they had absolutely no reason to implement the Name Constraints extension because if it ever appeared, it was guaranteed to be marked 'critical'.
Developers use the RFCs to write implementations. That's what RFCs are for. In this case, GlobalSign is issuing certs that are noncompliant in a direction that reduces the security experienced by users of compliant implementations.
I think this is wrong both in principle and in practice.
The alternative, which is also established practice, is to sell CA=YES certificates with no nameConstraints extension. What does the RFC say about that? Nothing. That's why bringing up the RFC is silly.
CA=TRUE with no nameConstrains is valid under the RFCs.
Whether or not one ought to rely upon a CA that would sell such a cert to a 3rd party is a question of trustworthiness which is (wisely) left out of scope for the RFCs.
Client app developers have a "root CA inclusion program" for this reason. It's more of a business process than a technical one. Mozilla's is probably the most publicly open and well-documented inclusion policy. I believe it also explicitly forbids the practice you describe.
We consider verification of certificate signing requests to be acceptable if it meets or exceeds the following requirements:
all information that is supplied by the certificate subscriber must be verified by using an independent source of information or an alternative communication channel before it is included in the certificate; [...] for a certificate to be used for SSL-enabled servers, 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 requirement clearly cannot be met by a root cert under which sub-CAs with no (or noncritical) name constraints are given to 3rd parties.
So how then does "the CA take reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate" when giving a 3rd party a private key which can sign a cert for any domain (and will be trusted by many clients the same as if had been issued by the CA itself)?
Here you go: https://wiki.mozilla.org/CA:CommunicationsFebruary 17, 2012 1) Subordinate CAs chaining to CAs in Mozilla’s root program cannot be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control, regardless of whether it is in a closed and controlled environment or not. Please review all of the subordinate CAs that chain up to your root certificates in NSS to make sure that they cannot be used in this way. Any existing subordinate CAs that can be used for that purpose must be revoked and any corresponding HSMs destroyed as soon as possible, but no later than April 27, 2012.
Note the word "cannnot" there. It's not "prohibited by contractual agreement", it's "destroy the HSMs containing the private keys".
Based on what's been said here, and on twitter (i.e. https://twitter.com/rmhrisk/status/300351604715057154 ), doesn't it appear that they are in violation of that requirement? Unless contracts and audits meet the requirement for "cannot."
The root programs all allow for technical and procedural controls to meet the this criteria. There are technical controls beyond name constraints as well.
Again GlobalSign's policies do not allow the use of certificates that chain to our roots to be used for MiTM purposes (or other malicious use cases for that matter) and we have controls in place that protect against such things occurring.
This is very comforting. After all, it's not like any CA "trusted" under those programs ever did Bad Things; certainly, these programs loudly warned about DigiNotar, TrustWave and TURKTRUST.
Perhaps they don't give you the actual cert, but merely issue it, keep on their premises and then let you use it for unlimited signing through some sort of API (that enforces the subdomain restriction)?
Because if they indeed are offering CA=yes certs, that's just plain unbelievable.
there is dNSName constraints but i don't know how well browsers support it. subordinate CAs seem quite problematic because they are invisible Certificate Authorities at least as far as the user is concerned.
My guess is it that, with this service, GlobalSign will create a sub-CA, but retain full control of it (i.e., own the key), issuing all the certificate themselves. Because of that they will be able to ensure that the customer owns all the hostnames.
Sure. Once they verify one or more root domain names, the customer can have control over their domain space (subdomains). EDIT: The control is enforced by having the customer issue the certificates via a GlobalSign-owned portal. (Disclaimer: I don't have any inside knowledge of what they actually do, but I believe this to be a reasonable assumption.)
If someone wants to be fully independent, the only way is to accept to be treated as a CA in their own right (and undergo all audits, etc).
How would a product allow an in-house CA to issue certificates for subdomains completely independently of GlobalSign without providing a CA=YES certificate?
"Third-party private (or enterprise) subordinate CAs: This is the case where a commercial CA has enterprise customers who want to operate their own CAs for internal purposes, e.g., to issue SSL server certificates to systems running intranet applications, to issue individual SSL client certificates for employees or contractors for use in authenticating to such applications, to issue SSL certificates for pre-approved domains that are owned/controlled by the customer, and so on.
These sub-CAs are not functioning as public CAs.
For these sub-CAs we need assurance that they are not going to start functioning as public CAs. Currently the only assurances available for this case it to ensure that these third parties are required to follow practices that satisfy the Mozilla CA Certificate Policy, and that these third parties are under an acceptable audit regime.
In Bug #394919 NSS is being updated to apply dNSName constraints to the CN, in addition to the SANs.
We plan to update our policy to require CAs to constrain third-party private (or enterprise) subordinate CAs so they can only issue certificates within a specified domain. See section 4.2.1.10 of RFC 5280."
If you feel uncomfortable about this trust decision made for you by OS
X, I would suggest taking a peek at the entire set of trusted root
certificates in /System/Library/Keychains/ (note that Keychain Viewer
hides one of them from view by default, so run:
open /System/Library/Keychains/*
from a shell).
I don't run OS X anymore, but I was not happy with what I saw at the time.
The problem with that idea is that the CA root store on your computer is a tiny subset of all the CA=YES certificates out there, because of intermediate chained CA certificates.
So what you really need is something that watches every CA cert your browser ever sees and then does detective work on them. Which is sort of what Moxie Marlinspike's Convergence project was doing.
I double clicked the "SystemCACertificates" and that seems to have added a fifth keychain to keychain access (it used to display four, I think). That didn't seem too bad, a few Geotrust and VISA items, and a bunch of DOD ones? Well, I guess it's a bit weird to have 20+ DOD certificates there.
(I already used keychain access some time ago to untrust CNNIC, Türktrust and Diginotar earlier)
Just to make sure I'm not confused. I can purchase a root certificate from this company? And this certificate will be seen as valid by the major browsers?
If I am not mistaken, that is exactly what they are claiming (albeit stressing that they are issued to be used for subdomains) but others have pointed out that that limitation is unenforceable (i.e. inexistent).
Is this against some sort of rule? They're allowing their clients to run their own delegate CAs, this can be very convenient for sysadmins. I'm not sure what's bad about it, or what new attacks it enables.
It may also give you the power to issue certificates for any name or, hopefully, it will be name constrained([1]). That's up to the CA however. The CA is taking on responsibility for all certificates issued under these cross-signs when they do this. Mozilla is currently in the process of requiring that these enterprise certificates either be name constrained, or be audited at the same level as roots.
I think Symantec will sell you much the same thing: http://www.trustico.com/material/DS_GeoRoot_0205.pdf
This is one of the reasons that we are pushing Certificate Transparency: http://www.imperialviolet.org/2012/11/06/certtrans.html
[1] X.509 Name Constraints allow an intermediate or root, CA certificate to be limited to issuing certificates within a certain scope, i.e. a domain. https://tools.ietf.org/html/rfc5280#section-4.2.1.10