The spec is silent about the content of the array buffers returned by getRemoteCertificates()
I have a slightly different question, which is why ArrayBuffer is used rather than RTCCertificate.
Well, ArrayBuffer is (probably) the DER-encoded end-entity certificate. That's pretty useful if you have a DER decoder I guess. RTCCertificate doesn't give you any information other than the expiration date.
getRemoteCertificates() can't return RTCCertificate because RTCCertificate instances can be used for creating a new RTCPeerConnection. That isn't possible for a peer certificate, since an RTCCertificate must include a private key.
It's getRemoteCertificates(), which would seem to imply that more than one certificate can be returned. There are scenarios in which it is possible for a certificate chain to be returned (e.g. a browser talking to a contact center gateway). However, how many WebRTC implementations currently validate a certificate chain used within DTLS?
The most typically suggested use of this method is to retrieve one or more certificates so as to be able to display information to the user. However, since it is up to the application what to do with the certificate(s), any information displayed to the user is potentially untrustworthy
Clarification for getRemoteCertificates()
A potential clarification for Issue 378:
I have submitted a PR that states that getRemoteCertificates() returns a DER-encoded certificate chain. However, it is not clear that there is WG consensus for this interpretation (or for an alternative one, for that matter).
Now defined (binary BER encoded).
getRemoteCertificates() behavior in "new" and "connecting" states
Issue #378 (not quite closed).
There still may be some ill-defined behavior when getRemoteCertificates() is called before the remote peer has selected a certificate. For example, getRemoteCertificates() could return null until RTCDtlsTransportState transitions to "connected".
Better to open another issue for this new problem.