Subject: [TLS] draft-rescorla-tls-subcerts-01

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Apr 2017 10:37:21 +0200

I read through draft-rescorla-tls-subcerts-01 and I ran into some basic
questions.

I have been wondering why the TLS server operator obtains an end-entity
certificate from a CA (which cannot be used to sign further
certificates) instead of running an intermediate CA him-/herself
instead. This would work without requiring any changes to the client
side. The proposed solution, although technically feasible, will
unfortunately take a long time to deploy since it requires cooperation
from clients, servers, and also from CAs.

What is also not clear to my why some of the certificate management
protocols, which provide the necessary level of automation, cannot be
used with CAs to request short-lived certificates.

Ciao
Hannes

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 21 Apr 2017 13:48:57 +0300

> from clients, servers, and also from CAs.

There is enormous amount of red tape obtaining intermediates, even
technically constrained ones. And as consequence, it is enormously
expensive (through not nearly as expensive as public CA).

Defining new extensions is much more deployable, as slow as it is
(AFAICT, no BR changes needed).

Regarding clients, I think the draft specifies LURK as backup plan
for clients that don't support subcerts (which causes some extra
latency if triggered).

> used with CAs to request short-lived certificates.

AFAIK, that would cause issues with CT and OCSP signing.

The latter would be fixable by reintroducing CABForum ballot 153 and
passing it (the reasons 153 failed were obviously political instead of
technical).

-Ilari

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Fri, 21 Apr 2017 11:08:00 +0000

On 21/04/2017 11:48, "TLS on behalf of Ilari Liusvaara" <[email-masked] on behalf of [email-masked]> wrote:
> AFAIK, that would cause issues with CT and OCSP signing.

Speaking as one of the co-authors of [1]: it is not completely clear to me what
is the limitation in CT that would prevent it to cope with the pervasive use of
short-term certificates.  Can anyone shed a light on this?

Cheers, thanks,
t

[1] https://tools.ietf.org/id/draft-sheffer-acme-star-00.txt

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 21 Apr 2017 15:50:23 +0000

> short-term certificates.  Can anyone shed a light on this?

I believe the concerns are scaling log servers and perhaps needing to "rotate" them if, say, 90% of their tree is invalid in a year.

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Sat, 22 Apr 2017 20:43:35 +0000

On 21/04/2017 16:50, "Salz, Rich" <[email-masked]> wrote:
> > Speaking as one of the co-authors of [1]: it is not completely clear to me
> > what is the limitation in CT that would prevent it to cope with the
> > pervasive use of short-term certificates.  Can anyone shed a light on this?
> 
> I believe the concerns are scaling log servers and perhaps needing to
> "rotate" them if, say, 90% of their tree is invalid in a year.

Thanks Rich.  I need to double check that, but I guess there are remedies for
the issues you mention -- e.g., adding more logs / having separate logs for
very short term stuff.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Apr 2017 17:39:39 +0200

Hi Ilari,

thanks for your response. A few remarks inline:

> expensive (through not nearly as expensive as public CA).

In essence you are doing this through the extension as well just using a
different format.

> (AFAICT, no BR changes needed).

I hope that this is true since otherwise you have just traded one
problem against the other one.

> for clients that don't support subcerts (which causes some extra
I didn't got that impression.

> passing it (the reasons 153 failed were obviously political instead of
Isn't this something ACME was trying to solve as well?

Ciao
Hannes

---

From: Melinda Shore <[email-masked]>
Date: Mon, 24 Apr 2017 07:52:46 -0800

> In essence you are doing this through the extension as well just using a

In some sense the proposal is about having a trusted issuer who's not
included in public trust stores, which is a reasonable goal (there's
a fantastic amount of work, including external audits, in having
your intermediate included in browser trust stores, etc.).  We haven't
had a good delegation story since, like, ever, but now there's a
somewhat compelling use case (CDNs) that needs attention and will
benefit from a solution.

Melinda

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 Apr 2017 16:05:06 +0000

> included in browser trust stores, etc.).  We haven't had a good delegation
> story since, like, ever, but now there's a somewhat compelling use case
> (CDNs) that needs attention and will benefit from a solution.

Emphasis on the somewhat.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 24 Apr 2017 19:32:59 +0300

> problem against the other one.

AFAICT, CAs can add arbitrary extensions if (logically sufficient but
not necressary):

- CA is "aware" of "a reason" to include it, and
- Extension has meaning on "public Internet", and
- Extension does not mislead w.r.t. CA validation performed

(CABForum Baseline Requirements, version 1.4.4, section 7.1.2.4).

For this, AFAICT:
- CSR requesting it or other kind of request is "a reason" to include
  it.
- Defined in RFCs for public use imples meaning on "public Internet".
- This extension does not affect CA validation.

Of course:
- Fixed process delay on CABForum for technical changes to BRs is
  ~7 weeks (1 week of discussion + 1 week of voting + ~4.3 weeks of
  IPR review + few days of misc. other). That's much faster than the
  time CAs take to actually offer this (if ever!).
- Nobody changes the extension rules in nasty ways for reasons I can't
  fathom of.

> Isn't this something ACME was trying to solve as well?

ACME can perform fast rolling of certificates. What it can't deal with
is any possible downsides to actually doing that in real world.

-Ilari

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Mon, 24 Apr 2017 21:06:24 +0000

Hi Hannes,

> I didn't got that impression.

Ilari is correct I think -- the fallback to LURK is what the draft in its
current version seems to imply.

> Isn't this something ACME was trying to solve as well?

We have proposed an extension to ACME that handles the full lifecycle of the
delegation, including the automatic renewal of the trail of short term
certificates.  It works in a pretty straightforward way and doesn't require any
modification in the endpoints' stack.

Cheers, t