Re: [Lurk] [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

Nick Sullivan <> Tue, 18 July 2017 11:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA6AD12F280; Tue, 18 Jul 2017 04:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bQNBsz3wPdzG; Tue, 18 Jul 2017 04:07:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC2681252BA; Tue, 18 Jul 2017 04:07:06 -0700 (PDT)
Received: by with SMTP id x187so13774766oig.3; Tue, 18 Jul 2017 04:07:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tq3jYZt/QV3exHH7BUYohwXf2B/h176cb1o6DmdlVFI=; b=ZCpqwuuZLcRD8vVOmYQAUH2MbXpPzndPHQAV7JygvySZzfoxUzNFZ7iypRKqZU7aCZ eT0y+o10/SDelvaIbrrnz3zgx0I304JlizLD74IEU/ClnWcEQ2k6eGqn5cgEM8rHbQKd fEEEKz/XekdCIRi5+IJ7pzICR+hovrejWpmJhQ7PsJGqBtzoh2r7ZB65zQ/dMyU69Hm2 GE8u1IIkb9xHDVXEgThzpeh2R26rLIaMlaZZlvVJfdwWqtHBqqEiUKC1rZE2ezleXcd3 Su7UpDMrNsybHg87pfG8qFRTvfM1gZP+SNxGzsL2mJFS0/CaAq9lxlaUWEgdA/om/IRQ qmSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tq3jYZt/QV3exHH7BUYohwXf2B/h176cb1o6DmdlVFI=; b=SFhjt9ZvSebztD+twW4FvQmkwkyPEwpXp4+ra4bfK2bK/wXykddVbC4ha3iEGS2Ycf Q6SbKnVBOjL6tj+5zLu7CRBtCb4BCM9Z45cOweGp1QauTUMCaUc6R88BGcC7jA5RMeQS TEpnJmMa6VaA+ncPQO5sdYO8rCf0xPCCJOwXJdELzQP7HsDeH7UCgqzR+CkROOcuxB0a GJ6dCtdOR5k151EMscRUaJl32pEKBqqduZXxTjC5JEheR4Cz06SDPsml9Z15sU+Ywi4n rfz+9592jLhgRjlU+PjBQcLDxap7j+oneexcMbgLvBvA/tgHfwwtxt8eet/Dkwyn73xD JE0Q==
X-Gm-Message-State: AIVw111mr6mHVYgqwKWAgwGazAMFVQkHJBtqE1Zb9t+1N9AHxjVxdvz6 EBDjmja+cdzR/75tlGqhvKXMbPgVzg==
X-Received: by with SMTP id m207mr639550oig.17.1500376026067; Tue, 18 Jul 2017 04:07:06 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Nick Sullivan <>
Date: Tue, 18 Jul 2017 11:06:55 +0000
Message-ID: <>
To: Sean Turner <>, "<>" <>
Content-Type: multipart/alternative; boundary="001a113d34ca103c6205549584ee"
Archived-At: <>
Subject: Re: [Lurk] [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Limited Use of Remote Keys <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Jul 2017 11:07:09 -0000


We've had some additional discussions in person here at IETF 99 with folks
who were in the proxy certificates and short-lived certs camp, and we think
there is now more agreement that the mechanism described in this draft is
superior to the alternatives. I've included a summary of some of the pros
and cons of the approaches:

*Proxy certificates vs. Delegated Credentials*
*Pro proxy certificates*:
- Already deployed in some industries, though not on the Web.
- Fits the conceptual model that public key == certificate.
*Con proxy certificates*:
- Proxy certificates adds additional complexity to the delegation other
than limiting the time period (full X.509, additional constraints  such as
- Encourages implementers to reuse PKIX libraries rather than build code as
part of TLS:
-- There have been problems and inconsistencies around pathlen and
constraints enforcement in existing PKIX libraries.
-- Modifying these libraries is more complex and risk prone than delegated
creds (which can easily be implemented in TLS as demonstrated by the 3
interoperable implementations at the IETF 98 hackathon).
- In proxy certificates, pathing is SKI dependent, not directly tied to EE
cert. This is a binding weaker than delegated credentials which includes a
signature over the EE certificate.

*Short-lived certs vs. Delegated Credentials*
*Pro short-lived certs*:
- Short lived certs work with existing libraries, no new code changes.
*Con short-lived certs*:
- Not widely available from CAs, especially for EV.
- Potentially problematic to the CT ecosystem (all certificates must be
logged in CT, which may bloat them).
- Introduces a high-risk operational dependency on external party:
-- Requires frequent exchanges with an external Certificate Authority (must
provide proof of domain possession to CA vs. internally managed credential
minter for delegated credentials).
-- There is no fallback if the CA has outage. With delegated credentials
you can fall back to a LURK-style protocol with the long-lived certificate

Given these comparisons, we think the proposed draft is the superior option
and would like to continue the discussion about adopting it.


On Fri, May 19, 2017 at 12:58 AM Sean Turner <> wrote:

> All,
> During the WG call for adoption, a couple of questions were raised about
> comparison/analysis of sub-certs versus proxy and/or short-lived
> certificates.  There is some discussion currently in the draft, but the
> chairs feel that these issues need further discussion (and elaboration in
> the draft) prior to WG adoption.  So let’s keep the conversation going.
> J&S
> > On Apr 12, 2017, at 15:31, Sean Turner <> wrote:
> >
> > All,
> >
> > At our IETF 98 session, there was support in the room to adopt
> draft-rescorla-tls-subcerts [0].  We need to confirm this support on the
> list so please let the list know whether you support adoption of the draft
> and are willing to review/comment on the draft before 20170429.  If you
> object to its adoption, please let us know why.
> >
> > Clearly, the WG is going to need to work through the trade-offs between
> short-lived certificates and sub-certs because both seem, to some, to be
> addressing the same problem.
> >
> > Cheers,
> >
> > J&S
> >
> > [0]
> _______________________________________________
> TLS mailing list