Hacker News Reader

Comment by tptacek | Hacker News Reader

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.

View on HN

I think you are misunderstanding.

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.

Ryan

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.

Argh.

As far as I'm concerned, that is in fact a MITM cert. Because you can technically MITM.

When it comes to crypto and the level of trust that the entire world puts into this, this is the only definition of "MITM cert" that matters.

You can only MITM Safari & Opera with that cert, FWIW.

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.

You seem to think that SSL is only for browsers.

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).

Ryan

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?

TACK can't get here fast enough!

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.

On a semi-related note check out how many governments have their own roots : http://unmitigatedrisk.com/?p=181

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.

I agree with Adam, support is actually quite good in modern libraries and this is in no small thanks to the good folks at NIST who published the PKITS tests for chain engines - http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitest...

Many libraries built these into regression tests for their chain engines and the suite covers name constraints pretty good.

If support is really that good, then you should have no problem following the RFC requirement that the name constraint extension be marked 'critical'.

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 did not create the subsidiary CA problem.

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.

Move the goalposts around much, Marsh? You're the one bringing Google up. I agree, that was a bad rhetorical strategy.

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.

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?

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 nameExtensions protect Chrome, IE and Firefox. They don't protect Safari.

Critical nameExtensions protect Chrome, IE, Firefox, and (because Safari will barf on them) Safari.

NO nameExtensions protects nothing.

Adam's point is simply that non-critical name extensions strictly dominate unconstrained certificates. His point isn't Orwellian at all.

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.

So, yeah, maybe it's more Overton than Orwellian.

The hell? Marsh, Adam Langley is one of the good guys.

The stuff he's talking about does exactly the opposite of what you claim it's surreptitiously doing.

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?)

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.

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.

No, the alternative is no more fucking 3rd party sub-CAs under widely trusted roots.

You've fallen for the old switcheroo.

Groan. Nobody gets to do anything to make HTTPS more secure until the world conforms to our norms?

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.

"We" are the relying parties.

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)?

Just look at the root program members in the Mozilla program, look at EFF data or the great notary.icsi.berkeley.edu/trust-tree/

As for disclosing all CAs have agreed to disclose -- no secret here at all.

And clearly from this thread I am being very open :)

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.

So are you proposing that 3rd party sub-CAs be brought under public CT?

I could get on board with that.

I believe for CT to "work" all CAs on the public internet need to participate.

I also believe that certificate transparency by itself is insufficient and the other items I mentioned are also needed.

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.

Gotcha, if the technology isn't in place to properly restrict the issued certs to only the customer's domains, that is bad.

I saw this on another site discussing Trusted Root certs:

> What is required to get a Root Signing Certificate?

> Each certificate provider has different requirements for trusted rootsigning certificates. Most will require something similar to the following:

> - Substantial net worth and insurance

> - A Certification Practice Statement (CPS) outlining your exact policies on issuing and managing certificates.

> - A FIPS 140-2 Level 2 compliant device to generate and managing your root certificate keys.

So it sounds like they are handing out the keys and then hoping that auditing/policies/insurance are in place to cover themselves.

> 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.

D'oh! I meant to write "effectively enforces" because I knew you'd snipe me with something like this. You win this time, Ristic.

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.

If that is a problem that impacts only one popular browser, I find it easier to cast blame at the feet of the browser.

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'.

Do you see the expressions of surprise about this policy here on HN? These are the world's more informed client application developers.

Careful. You're going to show up on "Shit HN Says".

Oh dude, make my day! :-)

http://tools.ietf.org/html/rfc5280#section-4.2.1.10

4.2.1.10. Name Constraints

...

Conforming CAs MUST mark this extension as critical

And? So they're not RFC compliant. Lots of things aren't.

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.

http://www.mozilla.org/projects/security/certs/policy/Inclus...

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.

It does not.

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:Communications February 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.

Perhaps if you described these technical controls in more detail we could reason about its security instead of by way of obscurity.

They need to meet the same criteria we do, here are some starting points but its far from exaustive:

http://www.mozilla.org/projects/security/certs/policy/

http://social.technet.microsoft.com/wiki/contents/articles/3...

http://www.webtrust.org/homepage-documents/item27839.aspx

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.

Another alternative is not to sell CA=YES certificates at all.

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.

Most will require that the private key be stored in an HSM (which almost certainly will be located on the customer's premises).

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.

The data sheet says that the product allows in-house CA's to issue certificates "completely independently" of GlobalSign.

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?

Reply on news.ycombinator.com