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

Eric Rescorla <ekr@networkresonance.com> Tue, 07 October 2008 13:59 UTC

Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55DE63A698B; Tue, 7 Oct 2008 06:59:50 -0700 (PDT)
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DE1F3A67F3 for <tls@core3.amsl.com>; Tue, 7 Oct 2008 06:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.46
X-Spam-Level:
X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PGkxP7q0ZU8 for <tls@core3.amsl.com>; Tue, 7 Oct 2008 06:59:48 -0700 (PDT)
Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id B04D63A698B for <tls@ietf.org>; Tue, 7 Oct 2008 06:59:47 -0700 (PDT)
Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id CBBD56B62F2; Tue, 7 Oct 2008 07:00:00 -0700 (PDT)
Date: Tue, 07 Oct 2008 07:00:00 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: martin.rex@sap.com
In-Reply-To: <200810071143.m97BhrV7013915@fs4113.wdf.sap.corp>
References: <200810071109.m97B9vFl011461@fs4113.wdf.sap.corp>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20081007140000.CBBD56B62F2@kilo.rtfm.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Verifying X.509 Certificate Chains out of order
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

At Tue, 7 Oct 2008 13:43:53 +0200 (MEST),
Martin Rex wrote:
> 
> Martin Rex wrote:
> > 
> > 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.
> 
> Thinking about it, what exactly do you mean with unordered?
> 
> Since there isn't any additional information in the protocol to
> identity the end-entity cert in the certificate_list, that certificate
> will have to be the first.  Or does your code really apply heuristics
> in locating the end entity cert?

This is an excellent point. It does seem rather problematic to
have multiple candidate EE certs, especially because in many
cases the SSL stack does not know the peer's expected name.

-Ekr
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls