2 ms·

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 i

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.
- marshray 14y ago
  No, the alternative is no more fucking 3rd party sub-CAs under widely trusted roots. You've fallen for the old switcheroo.
  - tptacek 14y ago
    Groan. Nobody gets to do anything to make HTTPS more secure until the world conforms to our norms?
    - marshray 14y ago
      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

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.

marshray 14y ago
No, the alternative is no more fucking 3rd party sub-CAs under widely trusted roots. You've fallen for the old switcheroo.
- tptacek 14y ago
  Groan. Nobody gets to do anything to make HTTPS more secure until the world conforms to our norms?
  - marshray 14y ago
    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