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

pgut001@cs.auckland.ac.nz (Peter Gutmann) Tue, 07 October 2008 03:26 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 F3BC53A6B32; Mon, 6 Oct 2008 20:26:48 -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 87E283A6B32 for <tls@core3.amsl.com>; Mon, 6 Oct 2008 20:26:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level:
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.900, 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 zGpw5H4xAPtk for <tls@core3.amsl.com>; Mon, 6 Oct 2008 20:26:46 -0700 (PDT)
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 82BEB3A6971 for <tls@ietf.org>; Mon, 6 Oct 2008 20:26:46 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C0AA819A83; Tue, 7 Oct 2008 16:27:22 +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 (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Za6E4qyyvr+9; Tue, 7 Oct 2008 16:27:22 +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 8781C19A5A; Tue, 7 Oct 2008 16:27:22 +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 7F8C819EC0BA; Tue, 7 Oct 2008 16:27:22 +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 1Kn3EI-0008Id-Cc; Tue, 07 Oct 2008 16:27:22 +1300
From: pgut001@cs.auckland.ac.nz
To: martin.rex@sap.com
In-Reply-To: <200810061845.m96IjcBV009717@fs4113.wdf.sap.corp>
Message-Id: <E1Kn3EI-0008Id-Cc@wintermute01.cs.auckland.ac.nz>
Date: Tue, 07 Oct 2008 16:27:22 +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:

>Looking at the official protocol spec, the possibility to send an empty list
>of certificate_authorities in the CertificateRequest message was introduced
>as a purely optional feature with TLS v1.1. It was _NOT_ previously allowed
>to send an empty list in the SSL v3 and TLS v1.0 specifications!

Yes it is.  The minimum length 3 can be used to encode a zero-length ASN.1
SEQUENCE (using BER encoding), there's nothing there that says it has to
contain anything.  I've been sending this in my certRequest for, oh, about 10
years now without running into any problems.

(Having said that, since client certs are so rarely used if there were
problems it's unlikely you'd ever see them, but in any case it's worked fine
so far).

>I think it is a pretty dumb engineering decision to create an implementation
>of SSL/TLS where it is possible to configure the Server to request a client
>Certificate and NO MEANS to configure the list of certificate_authorities for
>the ClientRequest message

Why?  The reason I never bothered to implement this is because I can't see any
use for it, if a server asks for a cert from the client then the client will
either use whatever cert it has for that server or respond "no-cert".  Even in
the unlikely situation that the client has multiple certs all intended for SSL
client auth (most users have zero certs for SSL client auth), unless every one
of them is specially chosen to be from a different CA then specifying the CA
name will have the same effect as specifying no CA name.

All this does is add uneccessary complexity (both to the implementation itself 
and for the user who has to configure it and deal with the results) and 
increase the attack surface.  If I was able to identify a good purpose for it 
(SSH uses exactly the same auth mechanism and gets by just fine without it) 
*and* if any user ever asked for it I'd think about adding support for it, but 
until then I've left it (along with a zillion other often-incomprehensible 
bits and pieces in standards) as a TODO.

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