Re: [TLS] Root certificates in server certificate chains

"Ryan Sleevi" <ryan-ietftls@sleevi.com> Wed, 01 September 2010 02:24 UTC

Return-Path: <ryan-ietftls@sleevi.com>
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 163F03A6859 for <tls@core3.amsl.com>; Tue, 31 Aug 2010 19:24:50 -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 CFO8Bsr8fPtg for <tls@core3.amsl.com>; Tue, 31 Aug 2010 19:24:48 -0700 (PDT)
Received: from homiemail-a66.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id AF1EE3A6834 for <tls@ietf.org>; Tue, 31 Aug 2010 19:24:48 -0700 (PDT)
Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 3D9C4350063 for <tls@ietf.org>; Tue, 31 Aug 2010 19:25:19 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sleevi.com; h=message-id:date :subject:from:to:reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=sleevi.com; b=KRZpTkml6r8uJ2 4Y0Z/L0otwcEeRJxDusuYBHddRglO9H7gt7drxG9DqKAN+/PbpWmDyquYvsYC3C/ ybZRTA0ntLggCWnp3fJq/oVQzvdj8yVCiiJoNCUzxug5bounGNfWn+OVhEnXO7dp lobfYvHfe+GJLkXn13Ip66ZXDV1eE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :date:subject:from:to:reply-to:mime-version:content-type: content-transfer-encoding; s=sleevi.com; bh=yMpBVSZ8LLPhph6/MKFg nvKiYO0=; b=UPBGshtMjhwBNCmiL2stHmt+yHWrne1bRPndKF02ieQZD+6VuKnW BlwilcOHtVnzK1xNIh/ffZhrUWl8kKrBq/kUP5hne4Zhhw7n66YOgIqXKUMcc9gD 5gmlTD0uDaleyVAku82z/aEiDpucjl4CHR0MOvMW4oP87ggYFVpJdKU=
Received: from webmail.sleevi.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) (Authenticated sender: ryan@sleevi.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPA id 3AB6A350014 for <tls@ietf.org>; Tue, 31 Aug 2010 19:25:19 -0700 (PDT)
Received: from 72.189.102.211 (proxying for 72.189.102.211) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.sleevi.com with HTTP; Tue, 31 Aug 2010 22:25:19 -0400
Message-ID: <2eda4b7b6eb5c5a0a61b2caf2c7d97bf.squirrel@webmail.sleevi.com>
Date: Tue, 31 Aug 2010 22:25:19 -0400
From: Ryan Sleevi <ryan-ietftls@sleevi.com>
To: tls@ietf.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [TLS] Root certificates in server certificate chains
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ryan-ietftls@sleevi.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-Archive: <http://www.ietf.org/mail-archive/web/tls>
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>
X-List-Received-Date: Wed, 01 Sep 2010 02:24:50 -0000

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
Marsh Ray
> Sent: Tuesday, August 31, 2010 9:57 PM
> To: Matt McCutchen
> Cc: 1.41421@gmail.com; tls@ietf.org
> Subject: Re: [TLS] Root certificates in server certificate chains
>
<SNIP>
>
> >> But, in this case, why allow the server to include a root
> certificate
> >> in the certificate chain in the first place?
> >
> > Perhaps as a hint to clients that might decide they wish to add that
certificate as a trust anchor, possibly after further research?
>
> To make it easier for users to "Permanently store this exception"?  :-P

What about the edge case of a server requesting a client certificate from
a trusted list of CAs, for which the client does not have the trusted root
in their list. This would apply both to 'simple' authentication
(Root->Intermediate->EE) and to the more complex scenario of bridge CAs,
where the client may have Root A->Intermediate->EE, but the server has
Root B->Intermediate'->EE, where Intermediate' is the cross-certified
certificate.

If the client feeds in the list supplied by the server into the list of
certificates to consider when building/evaluating a path to one of the
specified trusted CAs (as NSS does implicitly, AFAICT, and which OpenSSL,
Secure Transport, and SChannel all support), then the end-user should be
able to successfully build a path that contains one of the server
requested CAs.

Of course, such an implementation puts the onus on the clients to do this,
and there are alternatives that you could configure at the server (eg: by
specifying a request for Intermediate/Intermediate', rather than Root B),
but it seems valid/useful use case.

It can also act as a hint to the client of how much of the chain they need
to send. Consider if the client had EE->Intermediate->Root A->Root
A'->Root B, and the server indicated trust for Root A. If the client sent
EE->Intermediate->Root A->Root A' in their response, some servers that
have limited/partial implementation of the RFC 3280 path building
algorithms may have trouble building/validating the client certificate, as
they may only check the final certificate in the chain/final certificate's
issuer against their list of trust anchors, ignoring the fact that Root A
occurred earlier. This was the case with OpenSSL for a time, and with NSS
prior to libpkix integration, though I believe support for this scenario
has been improved in subsequent versions in the case of the former, and
certainly in the case of the latter.