Re: [TLS] Verifying X.509 Certificate Chains out of order

Steven M. Bellovin wrote:
> 
> On Mon, 06 Oct 2008 07:41:52 -0700
> Eric Rescorla <ekr@networkresonance.com> wrote:
> 
> > I think there are two separate issues here:
> > 
> > (1) Whether implementations should be required to send certificates
> >     in a specific order.
> > (2) Whether implementations should generate an error if they are
> >     received in another order.
> 
> "Be conservative in what you send; be liberal in what you accept."

That was my first thought, too.  :)

However, the really interesting question for a customer/consumer
of a technology is actually this variant of (2):

(2a) if interoperability of two independent implementations of TLS
     fail because one side aborts with a fatal error if it receives
     an unordered certificate_list, who is to blame?

Maybe it should be reworded to say

  "You MUST fix your implementation if you fail to interoperate
   with peers that report an error when receiving an unordered list

I recently had a customer complain because he would have liked to
use SSL client cert authentication with a particular kind of
middle box from a router vendor, but found himself unable to
configure that, because that middle box did not offer a possibility
to configure an certificate_authorities list to be sent in
the CertificateRequest message.

Looking at the official protocol spec, the possibility to send an
empty list of certificate_authorities in the CertificateRequest
message was introduced as a purely optional feature with TLS v1.1.
It was _NOT_ previously allowed to send an empty list in
the SSL v3 and TLS v1.0 specifications!

I'm aware that some implementations have been violating this
requirement in the SSLv3 and TLSv1.0 spec (instead of failing on
an incomplete configuration), but I think it is a pretty dumb
engineering decision to create an implementation of SSL/TLS
where it is possible to configure the Server to request a
client Certificate and NO MEANS to configure the list of
certificate_authorities for the ClientRequest message,
because this list MUST be sent to SSLv3 and TLS v1.0 client, and
it will also be required for interoperability with TLS v1.1+
clients that do not implement support for an empty list.

-Martin
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls