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

[Eric Rescorla <ekr at networkresonance.com>]

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 impFrom tls-bounces at ietf.org  Mon Oct  6 07:41:19 2008
Return-Path: <tls-bounces at ietf.org>
X-Original-To: tls-archive at ietf.org
Delivered-To: ietfarch-tls-archive at 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 at core3.amsl.com
Delivered-To: tls at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 840173A6A1E
	for <tls at 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 at 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 at 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 at networkresonance.com>
To: Simon Josefsson <simon at josefsson.org>
In-Reply-To: <87abdit8c2.fsf_-_ at mocca.josefsson.org>
References: <1223034323.30303.29.camel at localhost>
	<877i8pk772.fsf at mocca.josefsson.org>
	<1223281251.12502.74.camel at localhost>
	<87abdit8c2.fsf_-_ at 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 at kilo.rtfm.com>
Cc: tls at ietf.org
Subject: Re: [TLS] Verifying X.509 Certificate Chains out of order
X-BeenThere: tls at 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 at ietf.org?subject=unsubscribe>
List-Post: <mailto:tls at ietf.org>
List-Help: <mailto:tls-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>,
	<mailto:tls-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: tls-bounces at ietf.org
Errors-To: tls-bounces at 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 implementatlementations 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 at ietf.org
https://www.ietf.org/mailman/listinfo/tls


ions 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 at ietf.org
https://www.ietf.org/mailman/listinfo/tls