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

[Eric Rescorla <[e-mail]>]

On Thu, Jul 7, 2016 at 3:13 PM, Ilari Liusvaara <[e-mail]>
wrote:

> On Thu, Jul 07, 2016 at 12:28:33PM -0700, Eric Rescorla wrote:
> > We've talked several times about designing some sort of TLS delegation
> > mechanism. A few of us got together and put together some initial
> thoughts
> > about the options at:
> > https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt
> >
> > The general idea here is to have some mechanism for allowing what
> > are effectively end-entities to issue short-lived credentials that allow
> > other entities to act on their behalf (e.g., for CDN use cases).
> > Comments welcome.
> >
> > In terms of the security analysis, it's obviously very important that
> this
> > mechanism
> > not present a risk to existing TLS servers. The mechanism designed here
> is
> > intended to be future safe in that sense, though perhaps we've missed
> > something.
>
> - I think most browsers ignore KeyUsage presently, allowing the broken RSA
>   key exchange even when KeyUsage does not permit it. And as for server
> side,
>   I don't think many server products check the certificate they try to
> load,
>   just serve it mostly blindly.
>

This is my sense as well. That text in the document probably needs to be
rewritten.



> Also, what is the ServerNameList for? As far as I see, the delegated
> credential structure only contains one name. Or was it supposed to have
> multiple, but there was a typo in definition?
>
> Also why "SignatureScheme algorithm;" ... Doesn't digitally-signed already
> have a algorithm field?
>
> Also, doesn't digitally-signed "eat" all the fields inside? So if you
> want to actually transfer the data, you need the actual fields the second
> time?


All good catches. This was supposed to be more evocative than definitive,
and
we probably would have been better not providing any definition at all :)

-Ekr


>
> -Ilari
>