4 ms·

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

by rmhrisk 14y ago

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/pkitesting.html 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.

marshray 14y ago
If support is really that good, then you should have no problem following the RFC requirement that the name constraint extension be marked 'critical'.
- rmhrisk 14y ago
  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.
  - marshray 14y ago
    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?
    - tptacek 14y ago
      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.
      - marshray 14y ago
        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.
        tptacek 14y ago
        Move the goalposts around much, Marsh? You're the one bringing Google up. I agree, that was a bad rhetorical strategy.
        marshray 14y ago
        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.

by rmhrisk 14y ago

marshray 14y ago

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

rmhrisk 14y ago
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.
- marshray 14y ago
  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?
  - tptacek 14y ago
    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.
    - marshray 14y ago
      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.
      - tptacek 14y ago
        Move the goalposts around much, Marsh? You're the one bringing Google up. I agree, that was a bad rhetorical strategy.
        marshray 14y ago
        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.