Re: [TLS] Update spec to match current practices for certificate chain order

[[e-mail] (Martin Rex)]

Ryan Sleevi wrote:
> On Tue, May 12, 2015 12:04 pm, Martin Rex wrote:
>>  The *CORRECT* approach would be to issue a cross-CA certificate
>>  for (5) Root 2 signed by (4) Root 1, lets call it (5b), and
>>  the correct path to send for servers would be
>>
>>  (1)+(2)+(3b)+(5b)+(4)
>>
>>  that would be fully conforming with the existing requirements,
>>  fully comprehensible for clients that feed the certificate_list
>>  from the Certificate handshake message into "Basic Path Validation".
> 
> How did I know you would suggest this?
> 
> Ah, because I addressed it in the original email, when I said
> 
> "As much as you might wish to yell that they shouldn't have done (3a)/(3b)
> like that, and instead (5) should have been certified by (4), there are a
> large number of reasons why that doesn't happen, and the above is actually
> quite common (I know of at least three different organizations who will
> have to go through the above flow right now to avoid issues)"

there is no "shouldn't have done (3a)/(3b)".  They can simple create
that crossCA cert *NOW* and start distributing it, and things will
work just fine.

The problem with your original proposal is, that no *CORRECT* TLS
implementation will allow you to send such junk in a TLS Certificate
handshake message, so this will simply not be an option.

Right now, we still have a stick to make that CA create such a crossCA
cert.

But you're not only asking to make client tolerate junk, you seem to
be asking to actively break correct TLS implementations to start sending
junk and create new interoperability problems.


-Martin