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

Stefan Santesson <> Tue, 07 October 2008 10:03 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 4CFAC3A69D3; Tue, 7 Oct 2008 03:03:35 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C10173A69D3 for <>; Tue, 7 Oct 2008 03:03:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CGwQmQJFSoY8 for <>; Tue, 7 Oct 2008 03:03:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 95C093A6873 for <>; Tue, 7 Oct 2008 03:03:32 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 7 Oct 2008 11:04:05 +0100
Received: from ([]) by ([]) with mapi; Tue, 7 Oct 2008 11:04:05 +0100
From: Stefan Santesson <>
To: Peter Gutmann <>, "" <>
Date: Tue, 7 Oct 2008 11:04:03 +0100
Thread-Topic: [TLS] Verifying X.509 Certificate Chains out of order
Thread-Index: AckoLKM0vUsOIN/8SOWmy38l9m1ABwANqB0g
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [TLS] Verifying X.509 Certificate Chains out of order
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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: [] On Behalf Of
> Peter Gutmann
> Sent: den 7 oktober 2008 05:27
> To:
> Cc:
> Subject: Re: [TLS] Verifying X.509 Certificate Chains out of order
> Martin Rex <>; 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 mailing list