search

w3c / webrtc-pc

WebRTC 1.0 API
https://w3c.github.io/webrtc-pc/
Other
435 stars 115 forks source link

Strengthen generateCertificate expires capping #2137

Closed youennf closed 5 years ago

youennf commented 5 years ago

Currently the spec says that user agent MAY cap expires value. Implementations seem to cap by 1 year. We could strengthen the spec to say that user agent MUST cap expires value. We could suggest or mandate a maximum cap value, leaving the possibility for implementations to set a smaller cap.

lgrahl commented 5 years ago

I don't see any rationale for MUST but a guideline as part of a note or perhaps even a SHOULD is something I would support.

youennf commented 5 years ago

Current spec says MAY. If we upgrade it to SHOULD, why not going to MUST given that this cap is in place in major implementation? Spec would document what implementations are already doing.

lgrahl commented 5 years ago

Most WebRTC implementations also violate message integrity on data channels. The point being that just because it's being done, it doesn't necessarily justify moving it into the spec. :slightly_smiling_face:

Edit: I'm not saying there is no rationale for a MUST, I personally just haven't seen a rationale that would convince me to make it a MUST so far.

lgrahl commented 5 years ago

To elaborate, I believe just switching from MAY to MUST would not add any value if there's no concrete guideline. This is what I was arguing about in the above comments.

Going back to what @martinthomson stated:

Because browsers (or the users they act for) might not be well served by long-lived keys. And an expiration encourages/forces sites to deal with key changes. Maybe one days we will want to cleanly change requirements for keys and algorithms. Having keys expire prepares the ecosystem for that being something less than a massive disruption.

Based on that, it may make sense to say MUST limit to less than or equal to X but MAY go below that. Maybe I misinterpreted your previous comments and this is what you proposed.

IIRC @steely-glint makes use of this feature, so maybe he wants to add his two cents.

youennf commented 5 years ago

Based on that, it may make sense to say MUST limit to less than or equal to X but MAY go below that. Maybe I misinterpreted your previous comments and this is what you proposed.

Yes, I think we are on the same page then.

steely-glint commented 5 years ago

Yeah, we use it and I wouldn't have a problem with a MUST of say 1 year. Any lower could hinder usability. The problem comes when the expiry is shorter than the time between re-use of a periodically used system. Ideally don't want to have to push message people just to rotate their keys to the robo-lawn-mower every month of the winter when the thing is in the shed and probably powered down.

steely-glint commented 5 years ago

Given that these certs aren't backed up anywhere, any system has to have a way for a user to obtain fresh keys when the user loses their phone/resets it. So these are really a medium term distributed identity cache.

youennf commented 5 years ago

Fixed by https://github.com/w3c/webrtc-pc/pull/2181