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

Nelson B Bolyard <nelson@bolyard.me> Thu, 16 October 2008 01:39 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 66F253A6A3D; Wed, 15 Oct 2008 18:39:39 -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 6FA193A688C for <tls@core3.amsl.com>; Wed, 15 Oct 2008 18:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 5uX4uuMQfCjR for <tls@core3.amsl.com>; Wed, 15 Oct 2008 18:39:37 -0700 (PDT)
Received: from smtpauth17.prod.mesa1.secureserver.net (smtpauth17.prod.mesa1.secureserver.net [64.202.165.29]) by core3.amsl.com (Postfix) with SMTP id AD1023A6A3D for <tls@ietf.org>; Wed, 15 Oct 2008 18:39:37 -0700 (PDT)
Received: (qmail 20216 invoked from network); 16 Oct 2008 01:40:37 -0000
Received: from unknown (64.202.165.29) by smtpauth17.prod.mesa1.secureserver.net (64.202.165.29) with ESMTP; 16 Oct 2008 01:40:37 -0000
Message-ID: <48F69B89.1040308@bolyard.me>
Date: Wed, 15 Oct 2008 18:40:25 -0700
From: Nelson B Bolyard <nelson@bolyard.me>
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20080930003201 NOT Firefox/2.0 SeaMonkey/2.0a2pre
MIME-Version: 1.0
To: tls@ietf.org
References: <1223034323.30303.29.camel@localhost> <877i8pk772.fsf@mocca.josefsson.org> <1223281251.12502.74.camel@localhost> <87abdit8c2.fsf_-_@mocca.josefsson.org>
In-Reply-To: <87abdit8c2.fsf_-_@mocca.josefsson.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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

Simon Josefsson wrote, On 2008-10-06 01:51:

> We've received a request to verify X.509 certificate chains out of order
> in GnuTLS.  Doing that would violate the following in RFC 5246 (earlier
> versions had similar language), §7.4.2:
> 
>    certificate_list
>       This is a sequence (chain) of certificates.  The sender's
>       certificate MUST come first in the list.  Each following
>       certificate MUST directly certify the one preceding it.  Because
>       certificate validation requires that root keys be distributed
>       independently, the self-signed certificate that specifies the root
>       certificate authority MAY be omitted from the chain, under the
>       assumption that the remote end must already possess it in order to
>       validate it in any case.
> 
> It is claimed that OpenSSL, IE and Firefox does not enforce the second
> MUST in the paragraph above, and succeeds in verifying an
> out-of-sequence chain.  I haven't verified the claim.  It appears as if
> the OpenSSL developers don't consider their behaviour as a bug (see
> reply below).

I confirm the claim for Firefox and any other NSS-based applications.

NSS holds on to the first cert presented, and throws the rest into a
bucket, into which it has also thrown all locally trusted (i.e., root)
CA certs, and into which the application may have placed CA certs from
other cert chains that were successfully validated in the recent past.
Then beginning with the first cert that it received from the TLS peer,
NSS attempts to reconstruct a cert chain from the certs in that bucket,
one that leads to a locally trusted CA cert, and if it succeeds, it tests
the validity of that chain.  (This description is somewhat oversimplified.)
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls