Hacker News Reader

Comment by marshray | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com