W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2015

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

From: Harry Halpin <hhalpin@w3.org>
Date: Thu, 08 Jan 2015 15:19:23 +0100
Message-ID: <54AE91EB.6030604@w3.org>
To: Ryan Sleevi <sleevi@google.com>, GALINDO Virginie <Virginie.Galindo@gemalto.com>
CC: Justin Uberti <juberti@google.com>, public-webrtc@w3.org, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, Martin Thomson <martin.thomson@gmail.com>, Richard Barnes <rlb@ipv.sx>, Eric Rescorla <ekr@rtfm.com>

On 01/07/2015 07:14 PM, Ryan Sleevi wrote:
> I actually oppose such a call.
> I think too much of the discussion has happened on calls and conversations
> that lack sufficient record to provide guidance on the goals and
> requirements.

The main purpose of calls and face-to-face is to move past issues that
people are unable to do via email, as some email conversations can go on
forever and a teleconference can act as a forcing function.

That being said, having the WebRTC WG formulate their goals and
requirements via email is of course preferable - and your take on the
requirements are a good start.

I'm happy to delay (a month?) any telecon, but the option is open if
people want it.


> The original message I set forth tried to document the requirements as I
> had collectively had them presented over nearly half a dozen conversations
> with various participants. While I can understand the benefit of a
> high-bandwidth conversation, I would hope that taking a step back and
> looking at what is trying to be accomplished - divorced of any particular
> embodiment - would be more fruitful.
> On Jan 7, 2015 3:01 AM, "GALINDO Virginie" <Virginie.Galindo@gemalto.com>
> wrote:
>> 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.
Received on Thursday, 8 January 2015 14:19:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:03 UTC