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

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 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.
>