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

[pgut001 at cs.auckland.ac.nz (Peter Gutmann)]

Martin Rex <Martin.Rex at sap.com> writes:

>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!

Yes it is.  The minimum length 3 can be used to encode a zero-length ASN.1
SEQUENCE (using BER encoding), there's nothing there that says it has to
contain anything.  I've been sending this in my certRequest for, oh, about 10
years now without running into any problems.

(Having said that, since client certs are so rarely used if there were
problems it's unlikely you'd ever see them, but in any case it's worked fine
so far).

>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

Why?  The reason I never bothered to implement this is because I can't see any
use for it, if a server asks for a cert from the client then the client will
either use whatever cert it has for that server or respond "no-cert".  Even in
the unlikely situation that the client has multiple certs all intended for SSL
client auth (most users have zero certs for SSL client auth), unless every one
of them is specially chosen to be from a different CA then specifying the CA
name will have the same effect as specifying no CA name.

All this does is add uneccessary complexity (both to the implementation itself 
and for the user who has to configure it and deal with the results) and 
increase the attack surface.  If I was able to identify a good purpose for it 
(SSH uses exactly the same auth mechanism and gets by just fine without it) 
*and* if any user ever asked for it I'd think about adding support for it, but 
until then I've left it (along with a zillion other often-incomprehensible 
bits and pieces in standards) as a TODO.

Peter.
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls