Re: [TLS] New version of delegated credentials draft

Ryan Sleevi <> Thu, 09 March 2017 19:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8247D129471 for <>; Thu, 9 Mar 2017 11:45:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y7Ct6EwFA3O0 for <>; Thu, 9 Mar 2017 11:45:13 -0800 (PST)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B299012944E for <>; Thu, 9 Mar 2017 11:45:13 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 3D26AA003A0E for <>; Thu, 9 Mar 2017 11:45:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type;; bh=UBA/NoicBiwm9qlV96jPfebuoIA=; b= fHtceqXAd4cr0Rlk6Wky/g9o9NYLRg9XFIU/gWS4s2XzTkShHyjF8EA8KRKdUcyo CogXoogpvd/tJdlJvpZt1kt8YqztM+MwylIjTD6ysrhOrhJ+IE4VYsfE7mkpG5K9 ooA6uRAkTndP/91cPyUI9mQe92WxfI8b4orX79m5wnI=
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 05579A00012B for <>; Thu, 9 Mar 2017 11:45:13 -0800 (PST)
Received: by with SMTP id z15so10595364lfd.1 for <>; Thu, 09 Mar 2017 11:45:12 -0800 (PST)
X-Gm-Message-State: AMke39nxaBByi8JjjqmLmvGoJN5AYsZEp5SCcGX342B0x2dNhhRipZvgF6e1SCnq7qBDygwTexmwPOAKo6U4RQ==
X-Received: by with SMTP id d8mr3719016lfj.2.1489088711070; Thu, 09 Mar 2017 11:45:11 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 9 Mar 2017 11:45:10 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Ryan Sleevi <>
Date: Thu, 9 Mar 2017 14:45:10 -0500
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Ilari Liusvaara <>
Content-Type: multipart/alternative; boundary=f403045ea32ea99c20054a517b8c
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:45:14 -0000

On Thu, Mar 9, 2017 at 2:08 PM, Ilari Liusvaara <>

> 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.

Of course, no CT supporting clients support that method, and it's been
migrated to a (currently non-WG adopted) document in 6962-bis while things
are sorted. So if the argument is name-constraining is expected to
prevalent for case X (where X == redaction), I don't think that's the case.

> > * 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.

I'm going to push back on this assertion, because it came up during
previous discussions. The CA/Browser Forum's Baseline Requirements already
permit CAs to include additional X.509v3 extensions - specifically, Section of the Baseline Requirements - provided that the semantics that, if
included, will not mislead a relying party about the certificate
information verified by the CA.

As proposed, this (and the previous discussion) meet this definition, and
so without any change to policies, CAs can adopt this.

As a site operator with a business relationship with a given CA, you can
use that business relationship to request these extensions. Plenty of CAs
can and do respond to their customers' needs in a timely fashion, and/or
actively work to standardize them prior to immediately implementing. I
could name off examples for you, but I don't know if they need the free
advertising. The point being is that this doesn't require _all_ CAs to
change, it just requires "your" CA to change, and "your" CA is not going to
be constrained by any policies that prevent them from doing this.

If this were adopted, it might take time for the CA/Browser Forum to
normalize the policies around saying "Yes, this is OK" - and on that, I
agree, it's glacially slow (but about as quick as the full IETF process,
from chartering to publication, all things considered) - but again, you
don't need that.

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

It's not actually true anymore and hasn't been for some time, but I also
appreciate this is a subjective statement, so I understand that in the
absence of concrete data, your impressions may differ from my impressions.