- From: Harry Halpin <hhalpin@w3.org>
- Date: Sun, 11 Dec 2011 17:25:13 +0100
- To: public-identity@w3.org
On 12/11/2011 04:25 PM, Stephen Farrell wrote: > > Hi Tom, > > On 12/11/2011 04:37 AM, Tom Ritter wrote: >> On 9 December 2011 11:41, Stephen Farrell<stephen.farrell@cs.tcd.ie> >> wrote: >>> [1] http://tools.ietf.org/html/rfc5705 >> >> I thought I was on board with you Stephen, but after looking over that >> RFC I'm just not getting it. I'm a bit tired, but even after >> re-reading it a few times... It seems to just provide a RNG accessible >> on the client and server which uses the master secret as a partial >> input seed. Which is useful, but not what I was thinking of a priori. >> How far off am I with that? > > That's about it. The point though is that the master secret is > already securely (for whatever value of secure you associate with > TLS) on the other side. There's no need to develop a new key > transport/agreement protocol. That's a major plus, if the TLS > endpoints are already at the right places for doing application > layer crypto. > >> Thoughts I had which it definitely isn't: >> >> - A way to operate on things using the master secret of the >> underlying TLS connection > > Right. The API constructed here would have to build on 5705 to > provide an interface for using the TLS derived key to provide > confid. & integ. for an application layer plaintext. Something > like: > > TLSDerivedWrap(appstring, plain, cipher) for the sender > TLSDerivedUnWrap(appstring, cipher, plain) for the receiver > > The appstring would map to the 5705 label input. (Which might > or might not be an identity mapping, dunno.) Thought would be > needed on whether or how to try separate different applications > using the same TLS session. (Probably need to do that in any > case.) Note that if using the TLS extracted key I don't see > there'd be any need to define ways to separately use confid. > & integ. but that'd be one to discuss I guess. > > If TLS key extraction isn't suitable for an application then > it does need the usual pkcs#11-like functions and probably > needs to reinvent key transport, but I'd really like if we could > encourage the pattern above. > Right now DOMCrypt doesn't rely on TLS extraction and stays fairly simple, although it does replicate pkcs#11. I can't see us subtracting methods from DOMCrypt unless its current users and designers agree that it would be even *more* simple and provide for even more use-cases by using an automatically generated key build on top of 5705. DOMCrypt folks? However, if one has a TLS session, I don't see any reason why building on top of 5705 can't help. The main use-case seems to be just to simplify the generation of ephemeral (i.e. lifetime of key bound to a HTTP session, which in this case would be the TLS session) key material so that we won't need any key management/key transfer. But the downside is that key storage would be limited to ephemeral, which I thought at TPAC some people wanted to expand outside of, such as the pre-provisioned key use-cases. Any more thoughts/use-cases on this, Netflix and friends? >> - A way to operate on things using certificates (server and/or >> client) in the underlying connection >> - A way to expose parameters about the underlying connection to a >> higher-level protocol (e.g. certificates and chain in javascript >> parameters) > > The last one there also sounds reasonable. Not sure I get what > "operate on" might mean for the 2nd last one. I'd like some details on the precise parameters to be exposed. I think quite a bit of the "Korean Bank" use-case derives on figuring out what the minimal "operating" on is here. Channy suggested it might just be signing arbitrary blobs, and then perhaps downstream processing could then serialize that it the appropriate manner (I'm still not sure what precise kind of certificates the Korean Bank use-cases wants, ASN.1 client certs?). Correct? > > Cheers, > S. > >> >> The last bullet point I mentioned is something I've been pushing for a >> bit. Especially coupled w/ signing and verifying javascript libraries >> - you can implement key pinning and a number of interesting CA >> auditing and verification tools if you can read the supplied >> certificate parameters. >> >> -tom >> >
Received on Sunday, 11 December 2011 16:24:56 UTC