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

pgut001@cs.auckland.ac.nz (Peter Gutmann) Mon, 06 October 2008 12:49 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 F28B33A6A9E; Mon, 6 Oct 2008 05:49:46 -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 C93F43A6A9E for <tls@core3.amsl.com>; Mon, 6 Oct 2008 05:49:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.099
X-Spam-Level:
X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 tPSe1vRHg6ua for <tls@core3.amsl.com>; Mon, 6 Oct 2008 05:49:45 -0700 (PDT)
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id F27313A6A4B for <tls@ietf.org>; Mon, 6 Oct 2008 05:49:42 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 74EF09D6A4; Tue, 7 Oct 2008 01:50:18 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IH8QINQZkjSZ; Tue, 7 Oct 2008 01:50:18 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 189769D52C; Tue, 7 Oct 2008 01:50:17 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id C5EDF19EC0BA; Tue, 7 Oct 2008 01:50:16 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1KmpXU-0007ux-LQ; Tue, 07 Oct 2008 01:50:16 +1300
From: pgut001@cs.auckland.ac.nz
To: lists@drh-consultancy.demon.co.uk, pgut001@cs.auckland.ac.nz
In-Reply-To: <48E9FF47.2010503@drh-consultancy.demon.co.uk>
Message-Id: <E1KmpXU-0007ux-LQ@wintermute01.cs.auckland.ac.nz>
Date: Tue, 07 Oct 2008 01:50:16 +1300
Cc: simon@josefsson.org, 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

Dr Stephen Henson <lists@drh-consultancy.demon.co.uk> writes:

>This raises a point I've wondered about for a while... Various PKIX
>standards allow more than one chain between a root and EE certificate
>(cross certification et al) so the (possibly almost) complete one a
>server presents may not be the one a client will trust. CRLs can have
>distinct paths too.

That's the spaghetti PKI model.  Anyone who wants to get involved in that 
madness pretty much deserves what they get :-).

>The CMS standards for example don't have the ordering requirement they
>merely allow a set of "useful certificates" which may contain more or
>less certificates than necessary to build a chain.

I think they were bowing to the inevitable, people will stuff whatever they 
feel like into these things no matter what the spec requires.  Having said 
that I've never encountered a bunch of certs in a CMS object that didn't have 
an obvious path from the EE to some top-level CA cert.

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