Eric: I have not had a chance to look at the draft yet, but based on your cover note you seem to have several requirements in common with RFC 3820.
Russ On Jul 7, 2016, at 3:28 PM, Eric Rescorla <e...@rtfm.com> 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 also wanted to clarify a couple points about attacks where the certificate > that signs the delegated credential is also used for ordinary TLS operation > (which generally is a practice that's pretty scary). As noted above it's > important that existing certs not be usable this way, but maybe future certs > would be. > > 1. It's important to construct the delegated credential in such a way that > you can't use a TLS server as a signing oracle. If you choose "option 2" > where you define a new structure, then it's probably sufficient to use the > TLS 1.3 "context-including" digitally-signed production proposed by AGL. If > you you choose "option 1" where the delegated credential is an X.509 cert, > then you'd need to make some rules about fixing portions of the cert that the > TLS client can't control. > > 2. If you're concerned about attacks like those of Jager et al. which exploit > RSA decryption, what's important is that the attacker not be able to get the > server to do TLS 1.2-style static RSA with the key. Playing with the usage > bits definitely makes it harder to configure the server this way (because > it's likely to cause bustage) but may not be enough, because sufficiently > busted clients and server might be willing to use them that way anyway. > > In the next rev, we'll update the draft to make these points more clearly. > > -Ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
