2 ms·

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 o

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.

tptacek 14y ago
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.
- marshray 14y ago
  "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.
  - tptacek 14y ago
    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.
    - marshray 14y ago
      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.
- rmhrisk 14y ago
  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.
  - marshray 14y ago
    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)?
    - rmhrisk 14y ago
      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 :)
      - marshray 14y ago
        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.

tptacek 14y ago

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.

marshray 14y ago
"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.
- tptacek 14y ago
  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.
  - marshray 14y ago
    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.
rmhrisk 14y ago
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.
- marshray 14y ago
  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)?
  - rmhrisk 14y ago
    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 :)
    - marshray 14y ago
      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.