On Mon, Oct 3, 2016 at 5:24 PM, Jakob Bohm <jb-mozi...@wisemo.com> wrote: > On 03/10/2016 20:41, Kyle Hamilton wrote: >> WoSign is known to be cross-signed by several independent CAs (as well as > >> 2. There is only One Certificate Path that can be proven in TLS, which >> prevents risk management by end-entities. >> > > Are you sure, I thought the standard TLS protocol transmitted a *set* > of certificates in which the client could/should search for a chain > leading to a client trusted CA. For example, this is how cross- > certificates are often used by servers: Send the cross certificate for > the benefit of those clients that don't trust the (newer) root that > leads to the server cert.
Kyle is right. In TLS, you can only send one chain. The specification requires that the server send an ordered sequence of certificates. There is nothing in any TLS version that allows the server to send multiple independent certificate chains. For example I can't send these two at the same time: (server) -> Let's Encrypt Authority X1 -> DST Root CA X3 -> DST RootCA X1 (server) -> DigiCert Baltimore CA-1 G2 -> Baltimore CyberTrust Root -> GTE CyberTrust Global Root Even if there is only one private key for the server, you can't send multiple independent chains >> The primary reason why CAs have historically not been fully and >> unilaterally distrusted is because of the damage that would be done to the >> certified end-entities by distrusting the One Certificate Chain that can >> be >> provided via TLS. We need a means to provide multiple certificate chains >> simultaneously, with 1/N of those chains needing to pass verification in >> order for the connection to be deemed authentic. > > > The big limitation here is that most CAs have conditions of > certification that end entities are not allowed to submit the same > public key more than once, thus ensuring that each end entity public > key would be in only one cert from one CA. Sure. But you could do a threshold scheme where at least N chains have to be valid. You could even combine this with key pinning to require that at least N pins are met rather than the current scheme which is at least 1 pin is valid. >> This protocol would have permitted end entities to have multiple >> certificate chains from multiple providers, so that they wouldn't have had >> to go into crisis mode if one of their providers was distrusted. It also >> would have permitted in-protocol stapling of all necessary OCSP responses >> for validation. In other words, the One True Certificate issue (which has >> been known for several years as being the main reason why issuers could >> not >> be simply distrusted) has been worked around and worked around and worked >> around -- most recently with Certificate Transparency -- when the actual >> reason for the problem was simply "end entities cannot do risk management >> within the current protocols". It would seem the obvious tradeoff here is size. More chains means larger handshakes. It does have the advantage of allowing server operators to "set it and forget it" and still work even if one CA is distrusted. It wouldn't even require a change to signatures, it could just be an extra TLS message, something like "Alternative Server Certificate". Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
