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

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Hannes,

On 24/04/2017 16:39, "Hannes Tschofenig"  wrote:
> On 04/21/2017 12:48 PM, Ilari Liusvaara wrote:
> > 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.

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


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Melinda Shore]

On 4/24/17 7:39 AM, Hannes Tschofenig wrote:
>> 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.

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




signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hannes Tschofenig]

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
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

On 21/04/2017 16:50, "Salz, Rich"  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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

On 21/04/2017 11:48, "TLS on behalf of Ilari Liusvaara"  wrote:
On Fri, Apr 21, 2017 at 10:37:21AM +0200, Hannes Tschofenig wrote:
> > 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hannes Tschofenig]

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





signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls