On Thu, Jul 7, 2016 at 3:13 PM, Ilari Liusvaara <ilariliusva...@welho.com> 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
