3 ms·

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

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.
- marshray 14y ago
  Oh look, I have deep admiration for AGL. I like RMH too! I agree that they are "good guys". But this is not about the the person or the corporation. It's about the users of PKI and the massive existing code infrastructure (not just browsers) they rely upon today and the attacks to which our systems may or may not be vulnerable under the different CA issuance policies. RFC 5280: 4.2.1.10. Name Constraints: Conforming CAs MUST mark this extension as critical Sure, there are times when bending the rules of an RFC may be the right thing to do. But breaking this rule violates an interface contract critical for security, thereby retro-actively reducing the security of conformant implementations. Therefore, users and developers of existing security products must oppose this violation of RFCs.
  - tptacek 14y ago
    You keep citing the RFC as if it mattered. What matters in reality are the judgements of Microsoft, Google, Mozilla, and Apple (the HTTPS cabal). That this is annoying does not change its underlying truth. Of those four organizations, I feel like I could make a strong argument that Google is the one with the best activist stance on improving Internet privacy, the one doing the most to improve the core HTTPS infrastructure. The RFC you're citing is the product of a bunch of people sitting in a room talking. RFC policies do not bind organizations. About the most you can say about them is that they mean the HTTPS cabal is using something other than HTTPS. Ok, but that is the mother of all [sp]e[md]antic arguments. (Can we use "spemdantic" from now on?)
    - ivanr 14y ago
      The RFC may or not matter, but what does matter is doing the right thing. For example, if critical Name Constraints are not universally supported, does that make it right to use the non-critical ones? I don't think so. If Name Constraints are indeed important, I'd much rather see the CAB Forum first work with Apple until support is universal (or reasonably-well supported; whatever that means), and then start to use them.
      - tptacek 14y ago
        Careful: two different arguments here. One is what Google is doing, the other is what GlobalTrust is doing. While I'm not alarmed by what GlobalTrust is doing, I think CA's should not be in the business of selling CA=YES certificates to other organizations. No matter what X.509 allows them to express.
    - marshray 14y ago
      Oh, I hold no illusion of the infallability of the IETF process! But at the end of the day the world needs to have secure SSL/TLS applications. This requires it to be possible for "one skilled in the art" to be able to design and implement an application using this protocol. He must be able to understand the stated and implied requirements for security in order to have any chance of producing a secure application. And a secure application needs not just to interoperate well, but it must also refuse to interoperate insecurely, prevent impersonation, and so on. So if we can't end up with secure applications by writing them to the RFCs, then what the hell do we write them to? Where is this document defining all the ways in which CAs now and in the future feel free to relax the identity constraints which rely upon them to provide? If it is not possible for a competent and conscientious software developer to write a client application from existing documentation, rely upon a set of root CAs, and end up with a countably finite and well-bounded number of private keys in existence that can impersonate legitimate servers to his application then the CA system has failed in its one and only mission.
      - tptacek 14y ago
        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.

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.

marshray 14y ago
Oh look, I have deep admiration for AGL. I like RMH too! I agree that they are "good guys". But this is not about the the person or the corporation. It's about the users of PKI and the massive existing code infrastructure (not just browsers) they rely upon today and the attacks to which our systems may or may not be vulnerable under the different CA issuance policies. RFC 5280: 4.2.1.10. Name Constraints: Conforming CAs MUST mark this extension as critical Sure, there are times when bending the rules of an RFC may be the right thing to do. But breaking this rule violates an interface contract critical for security, thereby retro-actively reducing the security of conformant implementations. Therefore, users and developers of existing security products must oppose this violation of RFCs.
- tptacek 14y ago
  You keep citing the RFC as if it mattered. What matters in reality are the judgements of Microsoft, Google, Mozilla, and Apple (the HTTPS cabal). That this is annoying does not change its underlying truth. Of those four organizations, I feel like I could make a strong argument that Google is the one with the best activist stance on improving Internet privacy, the one doing the most to improve the core HTTPS infrastructure. The RFC you're citing is the product of a bunch of people sitting in a room talking. RFC policies do not bind organizations. About the most you can say about them is that they mean the HTTPS cabal is using something other than HTTPS. Ok, but that is the mother of all [sp]e[md]antic arguments. (Can we use "spemdantic" from now on?)
  - ivanr 14y ago
    The RFC may or not matter, but what does matter is doing the right thing. For example, if critical Name Constraints are not universally supported, does that make it right to use the non-critical ones? I don't think so. If Name Constraints are indeed important, I'd much rather see the CAB Forum first work with Apple until support is universal (or reasonably-well supported; whatever that means), and then start to use them.
    - tptacek 14y ago
      Careful: two different arguments here. One is what Google is doing, the other is what GlobalTrust is doing. While I'm not alarmed by what GlobalTrust is doing, I think CA's should not be in the business of selling CA=YES certificates to other organizations. No matter what X.509 allows them to express.
  - marshray 14y ago
    Oh, I hold no illusion of the infallability of the IETF process! But at the end of the day the world needs to have secure SSL/TLS applications. This requires it to be possible for "one skilled in the art" to be able to design and implement an application using this protocol. He must be able to understand the stated and implied requirements for security in order to have any chance of producing a secure application. And a secure application needs not just to interoperate well, but it must also refuse to interoperate insecurely, prevent impersonation, and so on. So if we can't end up with secure applications by writing them to the RFCs, then what the hell do we write them to? Where is this document defining all the ways in which CAs now and in the future feel free to relax the identity constraints which rely upon them to provide? If it is not possible for a competent and conscientious software developer to write a client application from existing documentation, rely upon a set of root CAs, and end up with a countably finite and well-bounded number of private keys in existence that can impersonate legitimate servers to his application then the CA system has failed in its one and only mission.
    - tptacek 14y ago
      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.