Re: Request from WebRTC

.setDTLSKey(AES) == ??
.setDTLSKey(RSA-PSS) == ??
.setDTLSKey(RSA-ES) == ??

I see no advantages to using WebCrypto to 'generate' the key.

What if you generate a WebCrypto key but set the usage as wrap?

It seems the only benefit is you like that there's an object called
Key. Everything else seems... undesired?

On Wed, Nov 13, 2013 at 10:50 PM, Richard L. Barnes <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> wrote:
>
>
>
>
> On Wed, Nov 13, 2013 at 7:24 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>
> On Wed, Nov 13, 2013 at 5:53 PM, Richard L. Barnes <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:07:20 UTC