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

Eric Rescorla <ekr@networkresonance.com> Mon, 06 October 2008 14:41 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 B10053A6A1E; Mon, 6 Oct 2008 07:41:19 -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 840173A6A1E for <tls@core3.amsl.com>; Mon, 6 Oct 2008 07:41:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.445
X-Spam-Level:
X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 RWtL5BwYpbbN for <tls@core3.amsl.com>; Mon, 6 Oct 2008 07:41:17 -0700 (PDT)
Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 6960A3A6932 for <tls@ietf.org>; Mon, 6 Oct 2008 07:41:17 -0700 (PDT)
Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 5B9596B57F6; Mon, 6 Oct 2008 07:41:52 -0700 (PDT)
Date: Mon, 06 Oct 2008 07:41:52 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Simon Josefsson <simon@josefsson.org>
In-Reply-To: <87abdit8c2.fsf_-_@mocca.josefsson.org>
References: <1223034323.30303.29.camel@localhost> <877i8pk772.fsf@mocca.josefsson.org> <1223281251.12502.74.camel@localhost> <87abdit8c2.fsf_-_@mocca.josefsson.org>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20081006144152.5B9596B57F6@kilo.rtfm.com>
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

At Mon, 06 Oct 2008 10:51:25 +0200,
Simon Josefsson wrote:
> 
> All,
> 
> 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).
> 
> For more details, including the particular certificate chain in this
> example, see:
> 
> http://thread.gmane.org/gmane.network.gnutls.general/1383/focus=1384
> 
> I can see several reasons to enforce the MUST recommendation here, e.g.,
> covert channels, DoS-considerations, unneeded complexity.

I think there are two separate issues here:

(1) Whether implementations should be required to send certificates
    in a specific order.
(2) Whether implementations should generate an error if they are
    received in another order.

Put me in the "Yes" category for (1). It makes the verifying 
implementation considerably easier. This isn't an issue if
you have a database-based verifier as is required for CMS,
but if you don't, then it's a lot easier to simply verify 
that C_n is verified by C_n+1. So, if you're doing just
a TLS stack and not a generic crypto stack, then this 
restriction helps. PureTLS cares about order.

As for (2), I think that's more debatable. The argument
against it is the usual flexibility argument. The argument
for it is early detection of nonconforming peers. Note that
I don't consider RFC 5246 to require enforcing this MUST.
It's simply silent on this point. Implementations which
verify out of order are still conforming, IMHO.

-Ekr

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