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

[Ilari Liusvaara <[e-mail]>]

On Mon, Apr 24, 2017 at 05:39:39PM +0200, Hannes Tschofenig wrote:
> Hi Ilari,
> 
> thanks for your response. A few remarks inline:
> 
> On 04/21/2017 12:48 PM, Ilari Liusvaara wrote:
> > On Fri, Apr 21, 2017 at 10:37:21AM +0200, Hannes Tschofenig wrote:
> >> 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.
> > 
> > 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).
> 
> In essence you are doing this through the extension as well just using a
> different format.
> 
> > 
> > Defining new extensions is much more deployable, as slow as it is
> > (AFAICT, no BR changes needed).
> 
> I hope that this is true since otherwise you have just traded one
> 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.

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