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

[Martin Rex <[e-mail]>]

Peter Gutmann wrote:
> 
> Martin Rex <[e-mail]> 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).

The problems aren't that obvious, because hardly anyone has been
using client certificates so far.   We've been using SSL client certs
for Single Sign-On with WebBrowsers for 8 years and 10k+ users, and
we've run into various interop problems with many implementations.

The semantics for an empty list were not defined in SSLv3 and TLSv1.0,
so there's nothing in the spec that says an empty list is allowed.
So the behaviour is at best "implementation defined", but it is definitely
not standardized.

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

Blindly relying on a feature that is at best "implementation defined"
is pretty much always a dumb engineering decision.


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

The situation that you describe as "unlikely" is the situation that is
going to be the norm when SSL client certs start getting used in a
serious fashion.

Lets try to explain the behaviour of a server not sending
a certificate_authorities list for common people:                
                                                                   
You walk up to a restaurant for a dinner.  The guard at the door   
tells you that you need a membership card in order to enter and    
hands you a form to fill in and prove your membership    however he
refuses to tell you which membership he will consider acceptable.  
Actually    he promises you that if you happen to pick one that    
is not acceptable, he will send you away with a painful kick in    
the butt.                                                          


Look at X509 certificates as you look at credit cards, customer cards,
membership cards and all the other plastic that populates your wallet.
There is never going to be just one, because each issuer want to retain
his very own authority to revoke his card -- and that should not interfere
with the validity of any of the other cards.

In the Web-Browser scenario, where the SSL protocol was born, that
kind of use and the availability of multiple SSL client cert has
been a design feature from the beginning.


Another serious problem of the "server sends nothing" approach is
that it requires the client to blindly perform an expensive public key
operation and this may incur the overhead/incovenience of prompting
the user to insert a hardware token and/or enter a PIN to authorize
a private key operation -- which can be entirely avoided if the
server announces what CAs it trusts and there is no match to
the credentials available to the client.


-Martin


_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls