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

[Hannes Tschofenig <[e-mail]>]

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.

> 
> 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).
I didn't got that impression.

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

Ciao
Hannes

> 
> 
> -Ilari
>