-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding key management interface #28
Conversation
Overall I like this but want to think about it more in the case where there is no bundle and we have multiple DTLS sessions. |
Since this is on the sending side only and we have a requirement to have a single consistent set of keys for the entire session, we can't possibly have a problem in that regard. If you want to have separate DTLS sessions with different credentials, you need multiple RTCPeerConnection instances anyway. See jsep:
I don't know why there is a "For DTLS" there still, but whatever. |
@@ -3463,6 +3524,49 @@ <h2 id="sec.stats-model">Statistics Model</h2> | |||
</section> | |||
|
|||
<section> | |||
<h2 id="sec.key-generation">Key Generation</h2> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not get really why this part could not be in a web crypto document we reference. That would be my preference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The feedback we got from the web cryptography files was that we were better off defining this and owning it. They were reluctant to take on an effectively useless key usage.
From the WebCrypto side, this seems very much an inappropriate use of WebCrypto, and is not something that was at all intended with the WebCrypto interface.
2.a) The choice of "Allow RSA-PSS even though it can't be used" is further example of the exceptional strangeness re: "future proofing"
To be clear, as a member of the WebCrypto WG, I am not just opposed to "including this in the WebCrypto API", as suggested in https://github.com/w3c/webrtc-pc/pull/28/files#r20125077 , but I am opposed to this use of WebCrypto entirely. The WebCrypto WG spent significant time haggling over naming and terminology in order to try to establish that the WebCrypto CryptoKey object was truly intended for explicit use with the low-level window.crypto.subtle interface. It is NOT meant to be a substitute for a "high level" key object, such as for a high-level key/identity API that has been discussed both in the WebCrypto WG and in various IGs, nor was/is it meant as a substitute for use with other protocols/APIs such as WebRTC. This isn't merely about turf, it's about providing spec and application authors - and the broader community - a set of reasonable paths to review the security and privacy implications of the APIs exposed. Indeed, the WebCrypto WG discussed quite a bit how unintentional combining of APIs can provide disastrous security experiences. There is nothing preventing the WebRTC WG from describing a new object that meets their use and security requirements. Indeed, WebCrypto's CryptoKey's are hardly the first object of this type - the File APIs' File object is a prime example. It would be better for application authors and security reviewers to consider introducing your own type here. |
Think this needs discussion on the mailing list not the bug tracker. |
Right, except there was no discussion I could find over the past four weeks Since this seemed just like one draft proposal, and because there was no If you can direct me to where this is being discussed, fantastic.
|
Sleevi, there is not an active discussion right now. It was discussed during the f2f at TPAC, but not since. And that was the first time, so I think that many are not up to speed. |
List discussion needed. |
This PR has caused considerable controversy on the mailing list. Apparently some people are calling for discussion of the use of the crypto API at the TAG. This PR is put on hold awaiting the outcome of that discussion. |
I'm going to close this and provide a new PR. |
Exposes local keying material and a control for it.
This doesn't do anything about presenting a view of the remote party keys.
For https://www.w3.org/Bugs/Public/show_bug.cgi?id=21880