Re: Issue 317: RTCDtlsTransport.start() with multiple RTCDtlsFingerprint

Robin Raymond said:

"RTCDtlsTransport only uses a single certificate. A non-ORTC remote implementation might offer multiple certs which is why we need to allow a sequence of remote fingerprints so we can validate the remote party. But ORTC DTLS will never use more than one certificate which is why it's not a sequence in the constructor."

[BA] While a RTCDtlsTransport will only select a single certificate in the DTLS handshake, WebRTC 1.0 provides for configuration of multiple self-signed certificates for use with a PeerConnection:

partial dictionary RTCConfiguration {
           sequence<RTCCertificate> certificates;
};

WebRTC 1.0 Section 4.2.1.1 says:

Although any given DTLS connection will only use one certificate, this attribute allows the caller to provide multiple certificates that support different algorithms.  The final certificate will be selected based on the DTLS handshake, which establishes which certificates are allowed.

In order for ORTC to support the same behavior, it appears to me that the DtlsTransport constructor needs to be provided with a sequence of certificates:


[Constructor(RTCIceTransport transport, sequence <RTCCertificate> certificates)]

Partial interface RTCDtlsTransport : RTCStatsProvider {

    readonly        attribute RTCCertificate        certificate<http://internaut.com:8080/~baboba/ortc/github/ortc.html#widl-RTCDtlsTransport-certificate>;

Since multiple certificates can be provided in the constructor but only one will be selected, a question arises as to the value of the certificate attribute.  If this reflects the certificate selected in the DTLS handshake, it will not be known when the DtlsTransport is constructed, so it presumably this will initially be unset.  When the certificate is selected, it will be set.  This should happen when (or perhaps before) DtlsTransportState transitions to "connected", so the application can wait for this transition before utilizing the certificate attribute (or calling getRemoteCertificates(), for that matter).

With respect to the behavior of getRemoteCertificates(), an Issue was filed and resolved:
https://github.com/w3c/webrtc-pc/issues/378

The resolution to this issue (see https://github.com/w3c/webrtc-pc/pull/431), assumes that the sequence of certificates returned by getRemoteCertificates() represents a certificate chain, rather than a sequence of self-signed certificates.  If getRemoteCertificates() is called in the "connected" state after the local and remote certificate(s) are selected, this makes some sense.  However, if getRemoteCertificates() is called in the "new" or "connecting" state while negotiation is still in progress,  the question is whether it should reflect the remote certificates that were offered, whether it should return null or throw an exception.