RE: Request from WebRTC

Guys,
I suggest we look at this in our F2F meeting tomorrow morning (Shenzhen time).
Regards,
Virginie


From: Richard L. Barnes [mailto:rbarnes@bbn.com]
Sent: jeudi 14 novembre 2013 07:50
To: Ryan Sleevi
Cc: Eric Rescorla; public-webcrypto@w3.org
Subject: Re: Request from WebRTC



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.


________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus