Re: [TLS] New version of delegated credentials draft

Ilari Liusvaara <> Thu, 09 March 2017 19:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D62DF1297D6 for <>; Thu, 9 Mar 2017 11:08:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 17X8iDx3ZWkG for <>; Thu, 9 Mar 2017 11:08:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 73B9B128824 for <>; Thu, 9 Mar 2017 11:08:36 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDC352596E; Thu, 9 Mar 2017 21:08:34 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id SQGSKtOdBKFI; Thu, 9 Mar 2017 21:08:34 +0200 (EET)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 574FE27B; Thu, 9 Mar 2017 21:08:34 +0200 (EET)
Date: Thu, 9 Mar 2017 21:08:28 +0200
From: Ilari Liusvaara <>
To: Subodh Iyengar <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] New version of delegated credentials draft
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Mar 2017 19:08:40 -0000

On Thu, Mar 09, 2017 at 04:50:24PM +0000, Subodh Iyengar wrote:
> Based on the comments during the last TLS WG meeting and the
> comments on the list, we've revised and submitted a new version
> of delegated credentials
> This has several salient changes from the previous version:
> * In the previous draft we described several alternatives.
> At the last WG meeting no one seemed particularly thrilled
> about using Name constrained certs directly, but there was
> some enthusiasm around either the custom structure or proxy
> certificates. With the changes to signing in this draft, the
> custom structure has some clear advantages, so we cleaned up
> the draft to remove all the alternatives except the custom
> structure.

On name constraints, name-constraining a wildcard certificate (e.g.
to "redact" data from CT) could be useful to avoid default-vhost
attacks against HTTP servers (there are lots of servers that
are misconfigured). Especially in HTTP/2.
> * Required the presence of an extension in the EE certificate
> to allow the use of delegated credentials.

I think this is going to be a major deployment problem. Basically,
CAs move pretty much glacially.

It is going to be much easier getting ECDSA certs (which are infamous
for being difficult to get[1]).

It seems that the only problematic SPKI OID is the general-purpose
RSA one: 1.2.840.113549.1.1.1.

One idea would be to restrict the extension OID to just those. Would
likely make those wanting delegated certs to reach out for ECDSA, but
it seems that most of the use of RSA when operator is actually able
to make "choice" is because of "compatiblity"[2]. And compatiblity
with ECDSA is of course no concern once subcerts are involved.

> * Clarified the behavior of TLS 1.3 and TLS 1.2 clients and
> servers.
> I hope that the cleanup in this draft should make it much
> easier to discuss going forward.

[1] Might not be actually true, but certainly ECDSA certs are more
difficult to get than ECDSA ones.

[2] The client support for ECDSA should be good enough already,
unless you explicitly need to (and this is extremely rare) support
very old clients.