IETF Logo Mail Archive

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

Martin Rex <Martin.Rex@sap.com> Tue, 07 October 2008 10:20 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 6944B3A696A; Tue, 7 Oct 2008 03:20:28 -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 5FC8F3A692C for <tls@core3.amsl.com>; Tue, 7 Oct 2008 03:20:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.81
X-Spam-Level:
X-Spam-Status: No, score=-5.81 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 QrG30bvPIPsZ for <tls@core3.amsl.com>; Tue, 7 Oct 2008 03:20:26 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 563E63A68D1 for <tls@ietf.org>; Tue, 7 Oct 2008 03:20:26 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id m97AKwTD021061; Tue, 7 Oct 2008 12:20:58 +0200 (MEST)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200810071020.m97AKucG008533@fs4113.wdf.sap.corp>
To: pgut001@cs.auckland.ac.nz
Date: Tue, 07 Oct 2008 12:20:56 +0200
In-Reply-To: <E1Kn30A-0007Qt-Gs@wintermute01.cs.auckland.ac.nz> from "Peter Gutmann" at Oct 7, 8 04:12:46 pm
MIME-Version: 1.0
X-Scanner: Virus Scanner virwal05
X-SAP: out
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
Reply-To: martin.rex@sap.com
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

Peter Gutmann wrote:
> 
> Martin Rex <Martin.Rex@sap.com> writes:
> 
> >All implementations that seriously care about (server) performance ought to
> >fail with an unordered certificate_list (and not try to reorder themselves).
> >Our OEM implementation does care.
> 
> Wow, how on earth did you manage to come up with an implementation where the
> overhead of doing this even registers?

(It's an OEM implemenation I happen to support, not my implementation.)

In a sensible PKI implementation there are distinct datatypes for
unordered bags of certs and an ordered certificate chain, and
the certificate chain verifier operates only on the ordered chain.
better modularisation of code, less bugs, less code, faster.

It makes perfect sense to require ordered lists in procotols such as in an
SSL certificate_list and X509PKIPathv1 in WS-Security and use unordered
lists only where performance has low importance (PKCS7/CMS) or usability
is desired (User interfaces).


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

v2.23.0 | Report a Bug | By Email