On Mon, Oct 3, 2016 at 9:44 PM, Peter Bowen <[email protected]> wrote:
> On Mon, Oct 3, 2016 at 5:24 PM, Jakob Bohm <[email protected]> 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 > TLS versions 1.2 and before explicitly required that you send an ordered chain but many servers in fact do not do so and browser clients generally will compensate for this. TLS 1.3 (grudgingly) acknowledges this fact and allows it, as long as there is only one EE cert: https://tlswg.github.io/tls13-spec/#certificate Note: Prior to TLS 1.3, “certificate_list” ordering required each certificate to certify the one immediately preceding it, however some implementations allowed some flexibility. Servers sometimes send both a current and deprecated intermediate for transitional purposes, and others are simply configured incorrectly, but these cases can nonetheless be validated properly. For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version, with the exception of the end-entity certificate which MUST be first. -Ekr _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
