Re: Request from WebRTC

On Wednesday, November 13, 2013 at 7:24 PM, Ryan Sleevi 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"
The upshot of the above is that if WebRTC is going to enable apps to manipulate keys (e.g., to refresh in order to avoid tracking), then they need some sort of opaque handle to the keys.   

The thought is that the WebCrypto Key interface provides an opaque handle to a cryptographic key.  So it would be unfortunate to invent another one.  

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