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

pgut001@cs.auckland.ac.nz (Peter Gutmann) Wed, 08 October 2008 12:12 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 67A4428C0CE; Wed, 8 Oct 2008 05:12:21 -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 BCE6C3A6A93 for <tls@core3.amsl.com>; Wed, 8 Oct 2008 05:12:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.037
X-Spam-Level:
X-Spam-Status: No, score=-6.037 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, 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 zgAsmbUYZxlG for <tls@core3.amsl.com>; Wed, 8 Oct 2008 05:12:18 -0700 (PDT)
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id 2853F3A6974 for <tls@ietf.org>; Wed, 8 Oct 2008 05:12:15 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 52789481795; Thu, 9 Oct 2008 01:12:41 +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 (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDbC3Y7RocUF; Thu, 9 Oct 2008 01:12:41 +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 3740C481774; Thu, 9 Oct 2008 01:12:41 +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 ECF0519EC0BA; Thu, 9 Oct 2008 01:12:40 +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 1KnXuC-00044h-Qp; Thu, 09 Oct 2008 01:12:40 +1300
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: martin.rex@sap.com
In-Reply-To: <200810071517.m97FHvqT028640@fs4113.wdf.sap.corp>
Message-Id: <E1KnXuC-00044h-Qp@wintermute01.cs.auckland.ac.nz>
Date: Thu, 09 Oct 2008 01:12:40 +1300
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>
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

Martin Rex <Martin.Rex@sap.com>; writes:

>But I really dislike the idea of expecting an empty DName (i.e. one that
>contains no RDName elements in the ASN.1 SEQUENCE) should have the same
>meaning as _NO_ DName at all!  Are you sure that this notion is interoperable
>with other implementations?

Because TLS client certs are so rarely used it's hard to say, the best I can
say is "I haven't run into problems so far", but that doesn't mean much given
the very small sample size.  A side-reason for leaving things this way is that
if anyone ever does run into this then it'll break in an obvious way, they'll
get back to me, and I can then get some hard data on what they're trying to do
with it and what sort of behaviour they expect from it.

As a generalisation, you'd be amazed at the total garbage you can put into
fields in security protocols and no-one notices.  Look at the (rather out of
date) shopping-list of certificate bugs in
http://www.cypherpunks.to/~peter/T2a_X509_Certs.pdf, there have even been
cases where major CAs have put random garbage (in some cases not even valid
ASN.1) into cert fields and no-one noticed.  So it could well be that
implementations are oblivious to whatever's in the CA-DN fields.  For example
since my code can't do anything useful with them it just skips them on read,
so there could be anything in there.  It's like TLS-Ext extensions (or X.509
extensions, or CMS attributes, or ...), if you can't figure out what to do
with something optional like this and it doesn't affect the protocol operation
then you can ignore it and continue.

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