- From: Richard L. Barnes <rbarnes@bbn.com>
- Date: Thu, 14 Nov 2013 00:44:41 -0800
- To: Ryan Sleevi <sleevi@google.com>
- Cc: Eric Rescorla <ekr@rtfm.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-ID: <EC4BE84D7A814A7A96E48154EEC1F1BC@bbn.com>
On Thursday, November 14, 2013 at 12:06 AM, Ryan Sleevi wrote: > .setDTLSKey(AES) == ?? > .setDTLSKey(RSA-PSS) == ?? > .setDTLSKey(RSA-ES) == ?? > > I see no advantages to using WebCrypto to 'generate' the key. How else would you do it? Some other JS API that references the same underlying key generation routines? > What if you generate a WebCrypto key but set the usage as wrap? > > Obviously, the intent is that only certain keys will be acceptable for use with WebRTC (likewise with the algorithms above). So there’s probably some check internal to PeerConnection.setDTLSKey() if (( /* algorithm not in acceptable algorithm set */ ) || ( /* proper key usages not in key.usages */ ) || ( /* key could be accessible to JS (e.g., extractable) */ ) { throw RefuseToUseThisKeyException(); } That doesn’t seem like a reason not to use WebCrypto, any more than the fact that other applications might only be able to use keys with certain properties. > It seems the only benefit is you like that there's an object called > Key. Everything else seems... undesired? > > Like I said before, there are at least these desirable properties: -- Key generation -- Key reference without JS access -- Key storage without JS access --Richard > > On Wed, Nov 13, 2013 at 10:50 PM, Richard L. Barnes <rbarnes@bbn.com (mailto:rbarnes@bbn.com)> wrote: > > > > On Wednesday, November 13, 2013 at 8:40 PM, Ryan Sleevi wrote: > > > > On Wed, Nov 13, 2013 at 7:39 PM, Eric Rescorla <ekr@rtfm.com (mailto:ekr@rtfm.com)> wrote: > > > > > > > > > > On Wed, Nov 13, 2013 at 7:24 PM, Ryan Sleevi <sleevi@google.com (mailto:sleevi@google.com)> wrote: > > > > > > On Wed, Nov 13, 2013 at 5:53 PM, Richard L. Barnes <rbarnes@bbn.com (mailto:rbarnes@bbn.com)> > > wrote: > > > > For those who might not have been following WebRTC, they are enabling > > browser-to-browser real time communications, using JavaScript. > > > > The good news is that all WebRTC communications are encrypted with keys > > negotiated using DTLS (using either SRTP or the DTLS for encryption). > > These > > keys are bound to user identities by way of identity assertions passed > > in > > SDP [draft-ietf-rtcweb-security-arch]. The challenge is that WebRTC > > apps > > want to be able to control what keys are used in the DTLS negotiation. > > > > The overall concept is that the app will be able to impose a key on the > > DTLS > > session, using something like a setDtlsKey() method. The question is: > > Can > > WebRTC use WebCrypto Key objects to represent keys used for DTLS? > > > > It appears that the answer to this question is “yes”. The app/key > > separation provided by the WebCrypto API provides the layer of > > separation > > that is needed. However, the WebRTC layer needs some additional > > metadata > > about the key: > > -- Whether the key was ever accessible to JS > > -- Limitation of the key to usage with DTLS > > > > > > These two statements make me think that WebCrypto is not the right fit for > > them. > > > > It is, in essence, stating "Were these keys ever Web Crypto keys" > > > > > > > > Hmm.... That seems like sort of a limited view. > > > > We want to: > > > > 1. Create keys > > 2. Push them around > > > > Why isn't that a legitimate use of WebCrypto? > > > > -Ekr > > > > > > You want to: > > 1. Create keys with an API > > 2. Know whether keys were used with this API > > 3. Push them around without using that API. > > > > Seems a bit of an odd use case. > > > > It also seems, from the use case, to revisit the whole notion of key > > discovery, which may carry UI implications, etc. > > > > But again, perhaps I don't fully understand what WebRTC is asking? > > > > > > The lifecycle is: > > 1. generateKey() - create keys > > 2. Store in IndexedDB for future use - shove it into storage > > 3. peerConnection.setDtlsKey() - shove it into the DTLS channel > > *. Ensure that the key isn’t used with any other WebCrypto methods. > > > > So maybe it’s a little weird in that the ultimate use is through the > > PeerConnection API and not WebCrypto. But the overall WebCrypto Key > > construct provides value by providing: > > -- A way to generate keys > > -- A way to safely store keys > > -- A way to let JS manipulate keys without direct access > > > > By my count, that’s 3 advantages to 1 weirdness. > > > > --Richard > > > > > > > > > > > > > > > > The proposal is to add information to the WebCrypto Key object to encode > > these metadata. > > > > This email is intended to be a summary, with more detail to be provided > > in > > discussion tomorrow. The main question for now is whether this seems > > like a > > current-API thing or a future-API thing. > > > > I would suggest that it is an issue for the current API, because (1) the > > proposed changes are small, and (2) if this is punted to a future > > version, > > then WebRTC will likely come up with an alternative solution. > > > > Thanks, > > --Richard > > > > > > Seems like a never-API to me, based on your summary, but perhaps I'm > > missing important context. > > > > >
Received on Thursday, 14 November 2013 08:45:12 UTC