Re: [TLS] draft-rescorla-tls-subcerts

Ilari Liusvaara <> Thu, 07 July 2016 22:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A062F12D14D for <>; Thu, 7 Jul 2016 15:13:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tKeQM7bJeiSh for <>; Thu, 7 Jul 2016 15:13:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B82DA12D100 for <>; Thu, 7 Jul 2016 15:13:28 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 52B4684AC; Fri, 8 Jul 2016 01:13:27 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id C7L3K5V_XxqJ; Fri, 8 Jul 2016 01:13:27 +0300 (EEST)
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 EDD482310; Fri, 8 Jul 2016 01:13:26 +0300 (EEST)
Date: Fri, 08 Jul 2016 01:13:24 +0300
From: Ilari Liusvaara <>
To: Eric Rescorla <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] draft-rescorla-tls-subcerts
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, 07 Jul 2016 22:13:31 -0000

On Thu, Jul 07, 2016 at 12:28:33PM -0700, Eric Rescorla wrote:
> We've talked several times about designing some sort of TLS delegation
> mechanism. A few of us got together and put together some initial thoughts
> about the options at:
> The general idea here is to have some mechanism for allowing what
> are effectively end-entities to issue short-lived credentials that allow
> other entities to act on their behalf (e.g., for CDN use cases).
> Comments welcome.
> In terms of the security analysis, it's obviously very important that this
> mechanism
> not present a risk to existing TLS servers. The mechanism designed here is
> intended to be future safe in that sense, though perhaps we've missed
> something.

- I think most browsers ignore KeyUsage presently, allowing the broken RSA
  key exchange even when KeyUsage does not permit it. And as for server side,
  I don't think many server products check the certificate they try to load,
  just serve it mostly blindly.
- I would definitely use TLS 1.3 signature construct for digitally-signed
  instead of TLS 1.2 one, as it mitigates some attacks (oh, you arlready
  mentioned it below).

Also, instead of extension one way that came to mind would be a new
CertficateType, where Cert#0 is the delgated credential and Cert#1 is
X.509 EE cert, and then comes the normal CA certs. Dunno which would be

I also checked if one could do some funky stuff with credential lifetime
notation to limit the lifetime. Nothing came up (apart for using 16-bit
count in decaseconds (das) only allowing presenting lifetimes up to 7
days, 14 hours, 2 minutes and 30 seconds). :->

Also, what is the ServerNameList for? As far as I see, the delegated
credential structure only contains one name. Or was it supposed to have
multiple, but there was a typo in definition?

Also why "SignatureScheme algorithm;" ... Doesn't digitally-signed already
have a algorithm field?

Also, doesn't digitally-signed "eat" all the fields inside? So if you
want to actually transfer the data, you need the actual fields the second