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

Looking over WebRTC 1.0, there does not seem to be a way to retrieve the selected local certificate, since getConfiguration() returns the same configuration (and certificates) passed to the RTCPeerConnection constructor, including the initial set of RTCConfiguration.certificates.  Not clear why developers would need to determine the selected (as opposed to the offered) local certificates, so that seems fine.

If that is correct, then to maintain WebRTC 1.0 compatibility, ORTC needs to:

1.       Make it possible to pass multiple certificates to the DtlsTransport constructor.

2.       Provide a read-only attribute for the certificates passed to the constructor.

Proposal:


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

Partial interface RTCDtlsTransport : RTCStatsProvider {

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

This implies that certificate<http://internaut.com:8080/~baboba/ortc/github/ortc.html#widl-RTCDtlsTransport-certificate>s will be set upon construction (to the certificates passed in the constructor).

getRemoteCertificates() still has some behavior that needs to be explained, since it will return null until the remote certificates have been selected (guaranteed to occur when RTCDtlsTransportState has transitioned to "connected").

Will work on WebRTC 1.0/ORTC PRs to explain this.

From: Bernard Aboba
Sent: Thursday, January 7, 2016 11:18 AM
To: public-ortc@w3.org
Cc: Robin Raymond <robin@hookflash.com>
Subject: 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.