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

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

If RTP and RTCP are not multiplexed, then separate DtlsTransports are needed for RTP and RTCP. If separate certificates are used for the RTP and RTCP DtlsTransport objects, then we have distinct fingerprints as well. The question is how to deal with the certificates and/or SDP signaling of the fingerprints (e.g. it is possible to have multiple a=fingerprint lines, but not to indicate which fingerprint is for RTP and which is for RTCP).  For example, should the RTP and RTCP DtlsTransport objects be required to share certificates (and fingerprints)?

Comment from Roman Shpount:

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.

Comment from Robin Raymond:


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.



 rshpount<https://github.com/rshpount> commented 9 minutes ago<https://github.com/openpeer/ortc/issues/210#issuecomment-106576744>
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.