RE: Re: Issue 218: DTLS: Problem with forking

On Tuesday, September 22, 2015 9:52 AM, Bernard Aboba wrote:
> 
> The proposed solution is to add support for the Certificate Management API introduced 
> into WebRTC 1.0, and also to add a certificate argument to the DtlsTransport constructor. 
> 
> The DtlsTransport object would now look like this: 
> [Constructor(RTCIceTransport transport, RTCCertificate certificate)]
> interface RTCDtlsTransport : RTCStatsProvider {
>      readonly    attribute RTCIceTransport            transport;
>     readonly    attribute RTCDtlsTransportState state;
>      RTCDtlsParameters     getLocalParameters ();
>      RTCDtlsParameters?    getRemoteParameters ();
>      sequence<ArrayBuffer> getRemoteCertificates ();
>      void                  start (RTCDtlsParameters remoteParameters);
>     void                  stop void ();
>                  attribute EventHandler?         ondtlsstatechange;
>                  attribute EventHandler?         onerror;
> };
> 

I think the RTCCertificate argument should be optional in the RTCDtlsTransport constructor.  This is consistent with WebRTC 1.0, where the certificate management API is optional, and by default certificates are created in the PeerConnection constructor.

Creating certificates upon object construction works for WEBRTC 1.0 and will also work for ORTC because as Martin Thomson suggested recently [1], with ECDSA the overhead of generating certs won't be significant even on older mobile devices. So, ECDSA certs can be created in the DtlsTransport constructor without excessive latency.  Note that ECDSA support is required in DTLS 1.2, which all WEBRTC and ORTC implementations need to support (and are moving towards). This is important because the key sizes required for secure RSA certificates (e.g. 2048 or larger) have become too burdensome.  If this approach is taken it will be up to applications to decide explicitly whether they need the Certificate Management API. 

Furthermore, if WEBRTC implementations move quickly to ECDSA, this may not be critical even when reusing certificates for DTLS forking - a read only attribute for the created certificate could be made available in DtlsTransport and then passed into a subsequent DtlsTransport constructor to enable reuse:

[Constructor(RTCIceTransport transport, optional ArrayBuffer certificate)]
partial interface RTCDtlsTransport : RTCStatsProvider {
     readonly    attribute ArrayBuffer certificate;
};

[1] http://lists.w3.org/Archives/Public/public-webrtc/2015Sep/0023.html

Received on Friday, 25 September 2015 18:02:32 UTC