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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
