- From: Harry Halpin <hhalpin@w3.org>
- Date: Fri, 25 Nov 2011 10:44:58 +0100
- To: public-identity@w3.org
On 11/25/2011 04:03 AM, Brian Smith wrote: > Mark Watson wrote: >> The possibility to develop secure application protocols in Javascript, >> without using TLS, is exactly the one of the points of this API, at >> least for us. > I do anticipate this work enabling substitutes for TLS. > > I wouldn't be surprised if some uses of key material and/or transmissions of key material were specifically restricted to authenticated and encrypted (i.e. TLS) connections by implementations. The key material is going to be traceable to the user's identity so it will likely have to be protected to the same extent as the user's identity is. > > Browser makers seem keen to prevent any new mixed content scenerios. AFAICT, that means that the browser has to understand at least some of the security properties of the transport security protocol used, to ensure that transport security protocol has the same/similar properties that TLS has. The easiest way to do that would be to just have all applications use TLS. If TLS isn't appropriate for some applications like streaming video, then we should have a (separate?) discussion of how that is going to work. > I think the issue at hand is that Mark wants to have for their use-case preprovisioned keys in some non-browser storage (i.e. *not local storage, but something in the platform that would prevent secret material being touched by the JS API I'd assume) accessed via operations of the JS API. That would of course run counter to Stephen's suggestion that the key always be extracted from the TLS session, although it does not preclude doing so. The question is - do we have enough use-cases to justify key storage/agreement or do we always want to just use (likely ephemeral) keys extracted from TLS? > - Brian >
Received on Friday, 25 November 2011 09:44:39 UTC