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

Martin Rex <Martin.Rex@sap.com> Tue, 07 October 2008 15:17 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 67ECA3A6A0D; Tue, 7 Oct 2008 08:17:31 -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 989123A6AD9 for <tls@core3.amsl.com>; Tue, 7 Oct 2008 08:17:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.945
X-Spam-Level:
X-Spam-Status: No, score=-5.945 tagged_above=-999 required=5 tests=[AWL=0.304, 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 DovMcV3+t9kF for <tls@core3.amsl.com>; Tue, 7 Oct 2008 08:17:25 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 9A1F13A6951 for <tls@ietf.org>; Tue, 7 Oct 2008 08:17:25 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id m97FI0wM014348; Tue, 7 Oct 2008 17:18:00 +0200 (MEST)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200810071517.m97FHvqT028640@fs4113.wdf.sap.corp>
To: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Tue, 7 Oct 2008 17:17:57 +0200 (MEST)
In-Reply-To: <E1KnDKN-0005hN-Q8@wintermute01.cs.auckland.ac.nz> from "Peter Gutmann" at Oct 8, 8 03:14:19 am
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:
> 
> >Would a zero-length ASN.1 SEQUENCE not require that DistinguishedName have a
> >zero length?
> 
> A zero-length BER encoding of a SEQUENCE would be 30 81 00, which meets the
> minimum-length requirements of 3 bytes.
> 
> (I'd always assumed that the limit of 3 bytes was specifically to allow this
> encoding of an empty DN, since it's not possible to get a DN that fits into 3
> bytes).

That interpretation appears quite confused to me.

First of all, the 3 bytes minimum is listed for the sequence of
DistinguishedName, and that includes a 2-byte length field for
the certificate_authorities<3..2^16-1> vector.

The zero-length BER encoding of a SEQUENCE would apply to the
DistinguishedName element only, but there the minimum length
ist listed as 1, not 3. (I was also mistaken about the actual encoding
of structure elements in TLS when I wrote my first posting on this).


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?

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