- From: tim panton <thp@westhawk.co.uk>
- Date: Wed, 24 Dec 2014 11:17:06 +0000
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Cc: Ryan Sleevi <sleevi@google.com>
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