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

[Stefan Santesson <stefans at microsoft.com>]

Just agreeing on the principle that implementers should be forced to send the certificates in order but it definitely must be allowed to accept out of order chains.
As long as I can use, some or all, of the provided certificates to construct a valid path, and I'm willing to undertake the effort to do so, then it would be quite senseless to force me to reject that path.

Also, In the practical world of cross-certification and bridge CAs, it is quite possible that I in any case as relying party only will use a subset of the provided certificates.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: tls-bounces at ietf.org [mailto:tls-bounces at ietf.org] On Behalf Of
> Peter Gutmann
> Sent: den 7 oktober 2008 05:27
> To: martin.rex at sap.com
> Cc: tls at ietf.org
> Subject: Re: [TLS] Verifying X.509 Certificate Chains out of order
>
> 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

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