Re: Request from WebRTC

The current concept is to focus on keys and self-signed certificates (as current WebRTC implementations are doing), with CA-issued certificates as future work.  

--Richard



On Wednesday, November 13, 2013 at 7:32 PM, Mountie Lee wrote:

> DTLS is based on Certificate which is not yet fully discussed in WebCrypto WG
>  
>  
> On Thu, Nov 14, 2013 at 11:24 AM, 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"
> >  
> > >
> > > 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.
> >  
>  
>  
>  
> --  
> Mountie Lee
>  
> PayGate
> CTO, CISSP
> Tel : +82 2 2140 2700
> E-Mail : mountie@paygate.net (mailto:mountie@paygate.net)
>  
> ======================================= PayGate Inc. THE STANDARD FOR ONLINE PAYMENT for Korea, Japan, China, and the World