Re: [TLS] Root certificates in server certificate chains

Matt McCutchen <matt@mattmccutchen.net> Wed, 01 September 2010 05:33 UTC

Return-Path: <matt@mattmccutchen.net>
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 E45B63A6AAB for <tls@core3.amsl.com>; Tue, 31 Aug 2010 22:33:27 -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 o6DAuV825H2m for <tls@core3.amsl.com>; Tue, 31 Aug 2010 22:33:24 -0700 (PDT)
Received: from homiemail-a61.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id DFB163A694F for <tls@ietf.org>; Tue, 31 Aug 2010 22:33:23 -0700 (PDT)
Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id 1381A57806C; Tue, 31 Aug 2010 22:33:45 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=XdxLZUixLas6dDN3NExgY0fRRUem+y7Jw282OluBOIq n/iJ/GV6GwvZMA2Plt35B5HCrAegKqHckTJ9yjX/pTqz2Y3r4IYo4QXoixWBPDOp XjDj69O0xjDIPLFXU/UcAorrKdYhjRkPVzIgUOefS+IsN0oPpKlv7JdR2xjJwL0g =
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=Q1wFhQNTS4PEPd+mbsOwX5RY0/E=; b=keAJ5c6tCm nwS64YWoKFrBxB3Yu60Y2l17GKyTJym6xRdbF/zkqZ+p1PsYz8oUvYd3WOxWIuIL AF9jBZgOExymBIUrv9NOSgofmlYaXKlF0T0loMRCM01DCZqjbIOku7ij8n2wrQ2x mF82N6O1fLLBqrqPZGz/NfEBJS/wjudE0=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPA id 83A2C578069; Tue, 31 Aug 2010 22:33:44 -0700 (PDT)
From: Matt McCutchen <matt@mattmccutchen.net>
To: ryan-ietftls@sleevi.com
In-Reply-To: <2eda4b7b6eb5c5a0a61b2caf2c7d97bf.squirrel@webmail.sleevi.com>
References: <2eda4b7b6eb5c5a0a61b2caf2c7d97bf.squirrel@webmail.sleevi.com>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 01 Sep 2010 01:33:43 -0400
Message-ID: <1283319223.2175.52.camel@mattlaptop2.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.2
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Root certificates in server certificate chains
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-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 05:33:28 -0000

On Tue, 2010-08-31 at 22:25 -0400, Ryan Sleevi wrote:
> 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.

This isn't a use case for the server sending a root certificate.  I
would assume that the client's chain, like the server's chain, MAY omit
the root certificate.  Then, the client can take Intermediate' from the
server's chain and simply send Client-Intermediate', where the issuer of
Intermediate' is Root B, matching the CertificateRequest.  The client
does not need the actual Root B certificate.

> 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, [...]

The server's CertificateRequest will contain Root A's distinguished
name, and the client should use that as the indication of where to stop.
Again, there is no benefit to sending the actual certificate for Root A.

-- 
Matt