Re: [TLS] Verifying X.509 Certificate Chains out of order (Peter Gutmann) Tue, 07 October 2008 12:25 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 4192F3A6B5F; Tue, 7 Oct 2008 05:25:02 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34E693A6861 for <>; Tue, 7 Oct 2008 05:25:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.849
X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bOVvMsgQgde8 for <>; Tue, 7 Oct 2008 05:24:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 16D793A689A for <>; Tue, 7 Oct 2008 05:24:58 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 81085481C03; Wed, 8 Oct 2008 01:25:22 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uWAZwMcSXtx5; Wed, 8 Oct 2008 01:25:22 +1300 (NZDT)
Received: from ( []) by (Postfix) with ESMTP id 662E9481BAC; Wed, 8 Oct 2008 01:25:22 +1300 (NZDT)
Received: from ( []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 2F9D619EC0BA; Wed, 8 Oct 2008 01:25:22 +1300 (NZDT)
Received: from pgut001 by with local (Exim 4.63) (envelope-from <>) id 1KnBcw-0000hC-1u; Wed, 08 Oct 2008 01:25:22 +1300
From: (Peter Gutmann)
In-Reply-To: <>
Message-Id: <>
Date: Wed, 08 Oct 2008 01:25:22 +1300
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: <>, <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

[Replying to two messages at once] writes:

>> I'd say modify it, in fact I'm not sure what the rationale for requiring
>> ordering was in the original spec, "it's tidier that way" doesn't strike me as
>> a good argument :-).
>Consider TLS on low-end or embeddede devices with limited ressources. Walking
>through the chain becomes difficult or even impossible if there is no order.

Again, how can you create an implementation that can run the entire SSL
protocol but can't manage a few 32-bit pointers across three or four certs?
This seems like a total red herring, it's difficult to think of an
implementation that can perform the necessary cert verification but somehow
can't manage an extra pointer swap.

(Well, I'm sure I can come up with some pathological case where you can do one
and not the other, but I'd have to apply some pretty creative thinking :-).

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

Oh, in that case there's nothing to worry about, if I can wait until PKI
starts working before I need to address it then I'm OK.

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

What a marvellously nonsensical example.  If I go to I
enter the password I use for Amazon.  If I need to provide a cert, I provide
the cert I use for Amazon.  End of story.  This procedure has worked just fine
for more than ten years now for SSH, which I'm sure has a much larger and more
diverse user base than client-side SSL certs ever will.

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

Sure, I'll admit that one's a real issue in the special situation where this
specific case applies.  OTOH I'm happy to leave things as they are until
client certs take off before I look at it further, I've got way too much other
stuff to work on that's more pressing than this.

And that's the real killer for this I think: If you're going to go with these
niche variations that almost no-one uses, you sort of have to accept that
you're going to be in a world of pain.

TLS mailing list