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

Re: Move forward with Key control APIs

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 13 Jan 2015 12:19:20 +0000
To: Martin Thomson <martin.thomson@gmail.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D13E0C5@ESESSMB209.ericsson.se>
On 13/01/15 00:53, Martin Thomson wrote:
> On 12 January 2015 at 06:10, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> #1. Anonymous calling: the correspondent doesn't care who the other side
>> is, so no identification is needed.
>> #2. Identified calling: there's some chain of evidence linking the
>> crypto keys used for the call to some mutually-known identity (probably
>> via an identity provider).
> This is separate to, and separable from, the identity work.  It's
> mostly useful in the absence of identity, though it can have some
> limitation application when identity is involved.

I agree to that.

> With Tim's example, key continuity provides pseudonymous
> identification of a peer.  However useful this is in some cases,
> linkability of this sort is a real liability when it comes to
> anonymous calling.
> Thus the proposal, which is to have every PeerConnection instance use
> new credentials unless an application overrides that.  That partly
> assumes we can agree to mandate ECDSA rather than RSA due to the cost
> of RSA key generation on limited clients.  I think that Justin
> currently has the token on that part of the issue.
> I don't think that there is any more to it than that.  Richard and
> Ryan seem to be arguing more over the interpretation of this basic
> requirement.  I don't see any evidence of a lack of understanding
> there, more a disagreement over how to interpret and address it.
> My suggestion is that you tell the interested parties to sort it out
> between themselves and come back with a recommendation to the group.
> I'm happy to translate any conclusion they make into a pull request.

I think that is what I am suggesting, looking for volunteer(s) to do 
this. But we have learned from history that only recommending what we 
should add to the spec is not sufficient. At some time someone may ask 
"why did you do this thing, and in this way", and then having archived 
use cases, requirements (in some form - I'm not looking for a full 
document, but perhaps in a mail to the list) and decisions help a lot.



Received on Tuesday, 13 January 2015 12:19:46 UTC

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