Re: Request from WebRTC

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


 >
> > 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.
>
>