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

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 Wednesday, 7 January 2015 11:02:22 UTC