Re: WebRTC Certificate Management - a plea to NOT use Web Crypto

That is Ryan's point #2, IIUC, but he is also putting forth point #1, which
is that a key object is the wrong abstraction for WebRTC to use here;
rather, it should be some form of serializable 'Identity' object, and the
fact that said object would contain a key (at least, at present) is simply
an implementation detail.

The general usage pattern here, for an application that wants key
continuity, would be as follows:

initial setup:
key = RTCGenerateKey();
serialize(key, storage);

placing a call:
key = deserialize(storage);
pc = new RTCPeerConnection({dtlsKeys: key});


On Wed, Jan 7, 2015 at 10:08 AM, Aymeric Vitte <vitteaymeric@gmail.com>
wrote:

> Reading this whole thread It's difficult to know what to think.
>
> Trying to summarize, if I understood correctly, basically Ryan is stating
> that nothing that is specced in WebCrypto does apply to the WebRTC keys, so
> even a WebRTC key compatible with WebCrypto would be of no use since it can
> not use anything from WebCrypto, except exportKey for public keys which is
> a trivial case, and that what is specced intentionnally does not apply to
> some crypto needs such as those of WebRTC, which can look surprising.
>
> Probably a code example about how WebRTC intends to use WebCrypto for the
> keys would be helpful.
>
> Le 07/01/2015 12:01, GALINDO Virginie a écrit :
>
>  Hi all,
>>
>> I am supporting the idea to set up a call between webRTC and Web Crypto
>> folks as suggested by Harry.
>> I think that to move forward the discussion, it would be helpful to
>> understand what are the special requirements that Web RTC keys do require
>> (a pointer to previous discussions would help me at least).
>>
>> We could also envisage to address special requirements in the next Web
>> Crypto WG deliverables, as Web Crypto WG is in the process of rechartering.
>>
>> Regards,
>> Virginie Galindo
>> Chair of Web Crypto WG
>>
>> -----Original Message-----
>> From: Harry Halpin [mailto:hhalpin@w3.org]
>> Sent: mardi 6 janvier 2015 10:31
>> To: Ryan Sleevi; Justin Uberti
>> Cc: Eric Rescorla; Martin Thomson; public-webcrypto@w3.org;
>> public-webrtc@w3.org; Richard Barnes
>> Subject: Re: WebRTC Certificate Management - a plea to NOT use Web Crypto
>>
>>
>>
>> On 01/06/2015 02:24 AM, Ryan Sleevi wrote:
>>
>>> On Mon, Jan 5, 2015 at 4:42 PM, Justin Uberti <juberti@google.com>
>>> wrote:
>>>
>>>> We did talk about it, and my takeaway at the time was that the best
>>>> path forward would be for WebRTC to define its own key-generate
>>>> function, and return an object that was API-compatible with WebCrypto
>>>> (so that we didn't have two different objects in the web platform to
>>>> represent 'key'). As Eric says, this became the basis of the current
>>>> proposal, so you can blame me for any misinterpretation.
>>>>
>>> Without trying to set out blame (since this was a conversation held
>>> with multiple people), I think the important thing to focus on here is
>>> "so that we didn't have two different objects in the web platform to
>>> represent 'key'"
>>>
>>> My original message, and my point of view, is to challenge
>>> 1) the idea that what WebRTC is dealing with is logically a 'key'
>>> 2) the idea that it's a bad thing to have two different objects for
>>> these two different APIs
>>>
>>> Put differently (to avoid both double negatives and ambiguity)
>>> - I do not think that WebRTC is dealing with anything that logically
>>> makes sense to be dealt with at a 'key' level binding
>>> - More importantly, that users and developers are better served by
>>> treating these two different APIs as different objects with different
>>> use cases
>>>
>>> I'm not sure how best to move this conversation forward. I see there
>>> being at least two areas of disagreement on this thread:
>>> - Cullen's assertion that WebRTC serves as a form of a crypto API, and
>>> thus we should strive for alignment
>>> - Richard's assertion that Web Crypto designed CryptoKey to be the
>>> basis for key objects
>>>
>>>  Although the larger question (should WebRTC use WebCrypto) is clearly a
>> WebRTC question, if people in both WebCrypto and WebRTC want to set up a
>> joint teleconference to sort this out, I'm happy to set it up at a time
>> convenient for both parties.
>>
>> In general, it should be expected that other standards in the future
>> build on WebCrypto. That being said, with W3C hat off, I think Ryan's
>> objections in this case make sense but again, we don't want two kinds of
>> 'keys.'
>>
>>            cheers,
>>                 harry
>>
>>> The former is a question for WebRTC WG, the latter is a question for
>>> the Web Crypto WG.
>>>
>>> While these could benefit from more discussion, I think the most
>>> important thing to do would be to keep in mind the priority of
>>> constituencies [1], and in particular, asking how the different
>>> proposed solutions work with developers' expectations. I think a
>>> solution that uses CryptoKey for WebRTC is going to fly in the face of
>>> a lot of expectations, and the only way in which it seems to align is
>>> in theoretical purity (since it provides no practical value to
>>> developers and nominal value for _some_ implementors)
>>>
>>> [1]
>>> http://www.w3.org/TR/html-design-principles/#priority-of-constituencie
>>> s
>>>
>>>  ________________________________
>>   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.
>>
>
> --
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
>