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

[Ilari Liusvaara <[e-mail]>]

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.
- I would definitely use TLS 1.3 signature construct for digitally-signed
  instead of TLS 1.2 one, as it mitigates some attacks (oh, you arlready
  mentioned it below).

Also, instead of extension one way that came to mind would be a new
CertficateType, where Cert#0 is the delgated credential and Cert#1 is
X.509 EE cert, and then comes the normal CA certs. Dunno which would be
better.

I also checked if one could do some funky stuff with credential lifetime
notation to limit the lifetime. Nothing came up (apart for using 16-bit
count in decaseconds (das) only allowing presenting lifetimes up to 7
days, 14 hours, 2 minutes and 30 seconds). :->


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?


-Ilari