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

Martin Rex <> Tue, 07 October 2008 11:11 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 2BD783A6B22; Tue, 7 Oct 2008 04:11:03 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 21F623A6B22 for <>; Tue, 7 Oct 2008 04:11:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.59
X-Spam-Status: No, score=-5.59 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E+Y8+j5HVspz for <>; Tue, 7 Oct 2008 04:11:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 19AB53A6864 for <>; Tue, 7 Oct 2008 04:11:00 -0700 (PDT)
Received: from by (26) with ESMTP id m97BA5Bk026150; Tue, 7 Oct 2008 13:10:12 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
To: (Stefan Santesson)
Date: Tue, 7 Oct 2008 13:09:57 +0200 (MEST)
In-Reply-To: <> from "Stefan Santesson" at Oct 7, 8 11:04:03 am
MIME-Version: 1.0
X-Scanner: Virus Scanner virwal05
X-SAP: out
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

Stefan Santesson wrote:
> 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.

I have absolutely no problem with implementations that accept an
unordered list.  However, implementations that accept an unordered
list should make sure they find a RELIABLE means to check that
they're always *SENDING* ordered lists, because a simple interop
check with their own client&server code or with other "unordered
accepting" implementations is NOT going to report bugs in
their *sending* implementation.

"Be liberal in what you accept" can be very dangerous with
careless implementors, because it will often make it more difficult
to verify whether your implementation is really conservative
with what it sends.  This may ruin the usefulness of
an originally sensible standard/spec.

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

I wouldn't be surprised if some implementations of PKI would follow AIA
while building a chain from an incomplete unordered set.
*I* certainly would not want *my* servers to do that.

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

That's a whole different can of worms.

It should be possible to chop off the overly complexx cross-cert and
bridge-CA nonsense and treat some intermediate CAs as trust anchors
instead.  This is more likely to work and makes failures much
easier to understand.  :)

TLS mailing list