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

["Ryan Sleevi" <[e-mail]>]

On Thu, May 7, 2015 3:49 pm, Geoffrey Keating wrote:
>  This answers the problem of multiple certificate paths, and doesn't
>  prevent re-ordering by the client, and also allows the server to guide
>  the client to the chain it prefers, which is important in some
>  circumstances.  For example, one chain might support EV, and another
>  might be necessary for older clients, but both might be valid in some
>  clients; the server would want to guide the client to the EV chain if
>  it will work.

The problem I have with that proposal is it conflicts with RFC 4158 and
conflicts with client practice [at least, those most likely to be
encountered at the web at large, in the context of HTTPS]

That is, yes, it's true, you can totally send based on the server's
preference, but there is zero obligation for the client to respect that
preference - and indeed, no clients that support path discovery (rather
than just path building) that I've observed actually would respect such an
order. That is, they do RFC 4158 style optimizations, ranging from caching
the certificate validation path to using application-determined
preferences (ranging from issuance date, key strength, etc)

This sort of goes back to it being a change to the path building APIs to
accommodate such language - the same reason that the current MUST is
ignored.

(Yes, I'm aware that libraries that simply perform path _verification_ -
notably, OS X's & iOS's Security.framework and OpenSSL & derivatives -
would implicitly respect such preferences. But they also fail fairly
miserably at dealing with the Web PKI, as evidenced by OS X's repeated
issues whenever there is a CA cross-signing or rollover, which has been
quite common the past few years, so I don't particularly consider their
behaviours emblematic of good behaviours)

Admittedly, it's harmless language from a client implementation side - but
I fear that by describing it as such, it sets up an indirect expectation
for servers and readers that clients SHOULD respect such ordering, when
there is no such requirement and it'd be even more work to do than the
current MUST.