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

Martin Rex <Martin.Rex@sap.com> Tue, 07 October 2008 14:11 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 396F13A67F3; Tue, 7 Oct 2008 07:11:18 -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 7BC2C3A67F3 for <tls@core3.amsl.com>; Tue, 7 Oct 2008 07:11:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.922
X-Spam-Level:
X-Spam-Status: No, score=-5.922 tagged_above=-999 required=5 tests=[AWL=0.327, 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 ker7kKvKTg1x for <tls@core3.amsl.com>; Tue, 7 Oct 2008 07:11:13 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 0C0163A67AB for <tls@ietf.org>; Tue, 7 Oct 2008 07:11:12 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id m97E9SGi002071; Tue, 7 Oct 2008 16:09:35 +0200 (MEST)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200810071409.m97E9GBd024151@fs4113.wdf.sap.corp>
To: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Tue, 7 Oct 2008 16:09:16 +0200 (MEST)
In-Reply-To: <E1Kn3EI-0008Id-Cc@wintermute01.cs.auckland.ac.nz> from "Peter Gutmann" at Oct 7, 8 04:27:22 pm
MIME-Version: 1.0
X-Scanner: Virus Scanner virwal05
X-SAP: out
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
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:
> 
> >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.

Looking at the TLS v1.0 spec again:

       opaque DistinguishedName<1..2^16-1>;

       struct {
           ClientCertificateType certificate_types<1..2^8-1>;
           DistinguishedName certificate_authorities<3..2^16-1>;
       } CertificateRequest;

Would a zero-length ASN.1 SEQUENCE not require that DistinguishedName
have a zero length?

TLS v1.1 added support for an empty list with this change:

      opaque DistinguishedName<1..2^16-1>;

      struct {
          ClientCertificateType certificate_types<1..2^8-1>;
          DistinguishedName certificate_authorities<0..2^16-1>;
      } CertificateRequest;

which allows certificate_authorities to be empty, but still requires
DistinguishedName to be non-empty (if sent).

(I admit I've never implemented SSL/TLS, so I'm not deeply intimate
 with the actual code).

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