W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2014

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

From: tim panton <thp@westhawk.co.uk>
Date: Wed, 24 Dec 2014 11:17:06 +0000
Cc: Ryan Sleevi <sleevi@google.com>
Message-Id: <6DCA3A3E-EA53-4A1E-9F23-3B7B49C9FE31@westhawk.co.uk>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
I’ve only just caught up on this thread/topic and admit to a degree of ignorance on it, 
but it does seem to me that the expectations of how crypto keys are used in webRTC are anything
but generic. Perhaps we would do better to take the same approach as we did with the data channel
and borrow some useful idioms from a pre-existing api (in that case web sockets) rather than 
trying to force the actual use of the whole api. So we’d just borrow some method names from webCrypto.

Personally I find it very hard to guess how we might want to manipulate/use keys in a webRTC 
environment - in experimenting with what is now available I have felt the need to generate keys for
use with specific web services, but to make those keys really useful I want to insert some values into
the well known X509 fields when the new key is created. The current proposal doesn’t allow for that.

There is also a possible sequence oddity where the getStats gives more info about the cert in use
than the rest of the api - so you know more about your own cert after the DTLS session starts than you did before.

That’s probably too late for services that want to check the certId _before_ allowing traffic.

Overall it isn’t clear to me that we have enough experience to come up with a good API design yet,
but that may just be my failing to see what is obvious to others.

Again - my apologies for catching up on this so late and being so vague.

Tim.
Received on Wednesday, 24 December 2014 11:17:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:42 UTC