6 ms·

Can you expand further on the practicality of the Name Constraints extension? My understanding is that not all browsers/libraries enforce them and IIRC, that ce

by ivanr 14y ago

Can you expand further on the practicality of the Name Constraints extension? My understanding is that not all browsers/libraries enforce them and IIRC, that certs that use them may not work in some browsers?

agl 14y ago
(Copying this reply of mine from another part of the thread as you're not the only person to ask.) Name Constraints support is pretty good in modern certificate libraries. It's certainly in CryptoAPI these days which accounts for the bulk of users. But there are two ways to use Name Constraints: they can be marked critical or non-critical. Critical Name Constraints are great, but they will cause anything that doesn't support Name Constraints to reject the certificate. This is obviously a problem because few deployments have much control over their client base. Non-critical name constraints provide a security benefit to clients that support them without affecting those that do not. Clients that don't support them are vulnerable to misuse of the constrained certificate, of course, but since the alternative is often an unconstrained, CA certificate, it's still a clear win.
- 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.
- ivanr 14y ago
  Let me rephrase the question: if Name Constraints are used and the extension is marked as critical (as 5280 requires), do you know (or can estimate or guess) what percentage of public users will not trust the certificate?
- marshray 14y ago
  Non-critical name constraints provide a security benefit to clients that support them without affecting those that do not. The sole raison d'être for the entire CA infrastructure is to prevent active MITM-style attacks. So from that perspective what you said is positively Orwellian. Noncritical name constraints absolutely do affect clients that don't support them. It reduces their security by making them vulnerable to MitM! The entire purpose of the critical flag was to allow evolving the PKI system without reducing security for existing systems. We ought not set the flag FALSE because the CA's big customers prefer flexibility to the security of the whole ecosystem. Clients that don't support them are vulnerable to misuse of the constrained certificate, of course, but since the alternative is often an unconstrained, CA certificate, it's still a clear win. A false dichotomy being imposed by a well-funded minority for which it serves their interests.
  - tptacek 14y ago
    Non-critical nameExtensions protect Chrome, IE and Firefox. They don't protect Safari. Critical nameExtensions protect Chrome, IE, Firefox, and (because Safari will barf on them) Safari. NO nameExtensions protects nothing. Adam's point is simply that non-critical name extensions strictly dominate unconstrained certificates. His point isn't Orwellian at all.
    - marshray 14y ago
      non-critical name extensions strictly dominate unconstrained certificates Don't you see how, once again, the CA industry has shifted the debate from the level of security everyone expected them to provide all along to another lesser of two evils? The discussion isn't about whether or not we must require name constraints on 3rd-party sub-CAs to be marked 'critical'. The issue is that the world of SSL/TLS client application users and developers believe, expect, and rely upon the non-proliferation of private keys with the ability to forge identities for the servers to which they connect. So, yeah, maybe it's more Overton than Orwellian.
      - tptacek 14y ago
        The hell? Marsh, Adam Langley is one of the good guys. The stuff he's talking about does exactly the opposite of what you claim it's surreptitiously doing.

by ivanr 14y ago

agl 14y ago

(Copying this reply of mine from another part of the thread as you're not the only person to ask.) Name Constraints support is pretty good in modern certificate libraries. It's certainly in CryptoAPI these days which accounts for the bulk of users. But there are two ways to use Name Constraints: they can be marked critical or non-critical. Critical Name Constraints are great, but they will cause anything that doesn't support Name Constraints to reject the certificate. This is obviously a problem because few deployments have much control over their client base. Non-critical name constraints provide a security benefit to clients that support them without affecting those that do not. Clients that don't support them are vulnerable to misuse of the constrained certificate, of course, but since the alternative is often an unconstrained, CA certificate, it's still a clear win.

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.
ivanr 14y ago
Let me rephrase the question: if Name Constraints are used and the extension is marked as critical (as 5280 requires), do you know (or can estimate or guess) what percentage of public users will not trust the certificate?
marshray 14y ago
Non-critical name constraints provide a security benefit to clients that support them without affecting those that do not. The sole raison d'être for the entire CA infrastructure is to prevent active MITM-style attacks. So from that perspective what you said is positively Orwellian. Noncritical name constraints absolutely do affect clients that don't support them. It reduces their security by making them vulnerable to MitM! The entire purpose of the critical flag was to allow evolving the PKI system without reducing security for existing systems. We ought not set the flag FALSE because the CA's big customers prefer flexibility to the security of the whole ecosystem. Clients that don't support them are vulnerable to misuse of the constrained certificate, of course, but since the alternative is often an unconstrained, CA certificate, it's still a clear win. A false dichotomy being imposed by a well-funded minority for which it serves their interests.
- tptacek 14y ago
  Non-critical nameExtensions protect Chrome, IE and Firefox. They don't protect Safari. Critical nameExtensions protect Chrome, IE, Firefox, and (because Safari will barf on them) Safari. NO nameExtensions protects nothing. Adam's point is simply that non-critical name extensions strictly dominate unconstrained certificates. His point isn't Orwellian at all.
  - marshray 14y ago
    non-critical name extensions strictly dominate unconstrained certificates Don't you see how, once again, the CA industry has shifted the debate from the level of security everyone expected them to provide all along to another lesser of two evils? The discussion isn't about whether or not we must require name constraints on 3rd-party sub-CAs to be marked 'critical'. The issue is that the world of SSL/TLS client application users and developers believe, expect, and rely upon the non-proliferation of private keys with the ability to forge identities for the servers to which they connect. So, yeah, maybe it's more Overton than Orwellian.
    - tptacek 14y ago
      The hell? Marsh, Adam Langley is one of the good guys. The stuff he's talking about does exactly the opposite of what you claim it's surreptitiously doing.