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.
You've fallen for the old switcheroo.
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.
"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.
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.
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.
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)?
As for disclosing all CAs have agreed to disclose -- no secret here at all.
And clearly from this thread I am being very open :)
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.
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.
I could get on board with that.
I also believe that certificate transparency by itself is insufficient and the other items I mentioned are also needed.