Issue 210: Certificates and Fingerprints in the non-mux case

Filed by Bernard Aboba:
https://github.com/openpeer/ortc/issues/210

This is both an issue with ORTC API as well as a backward-compatibility issue with WebRTC 1.0.

Roman said:

"Normally you create a single temporary certificate that you use for all RTP and RTCP streams. One certificate means one fingerprint. There are distinct DTLS sessions for RTP and RTCP streams but they reuse the same certificate. Remote certificate is validated using the same signature in each DTLS session but all sessions can use different crypto settings and keying material. Furthermore, it is recommended to setup up one DTLS session first and to setup the subsequent sessions between the same peers using session resumption. You can also specify multiple fingerprints in SDP. If any one of the fingerprints matches the remote certificate after the negotiation, you would consider this certificate acceptable and authenticated. So, you can use two different certificates for RTP and RTCP, provide two fingerprints and both DTLS sessions would get authenticated. Multiple fingerprints and different certificate are fairly theoretical at this point since I am not aware of any implementations that actually do this."

Robin Raymond said:


"Right, makes sense, but as of right now the RTCDtlsTransport objects for RTP vs RTCP are not the same object. Therefor they need not be the same fingerprint. So if SDP (and more importantly) implementations expect a single fingerprint we have to ensure that it is supported. So my opinion is that either the RTCP based on an RTP transport borrows the same certificate OR we use the certificate management API as proposed for WebRTC 1.0 [see w3c/webrtc-pc#214<https://github.com/w3c/webrtc-pc/pull/214> ] which would allow control over which certificate(s) were used for each RTCDtlsTransport object created.

[PS. I didn't mean to create a cross link onto the w3c issue/repo; that was auto-created by github; I'm surprised it allowed since I have no permission on that repo"

Roman replied:
"I would think that RTCP based on an RTP transport should borrow the same certificate, which will make things much cleaner. Certificate management API is much more advanced option and should only be required when more complex scenarios are needed

"