Hacker News Reader

Comment by tptacek | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com