Re: Section 15: Certificate Management API

Personally, I don’t see why you’d construct an object from an entirely different object. I’d prefer to see factory methods on the object that constructs it…

R



On July 6, 2015 at 6:13:57 PM, Peter Thatcher (pthatcher@google.com) wrote:

Then why don't we make it RTCDtlsCertificate with DtlsTransport.getCertificate?

On Mon, Jul 6, 2015 at 2:55 PM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
Yes, the WebRTC 1.0 Certificate Management API is only for DTLS certificates.
So the assumption is that they are self signed, do not contain a client user identity, etc. which constrains the required functionality.




On Jul 6, 2015, at 1:49 PM, Peter Thatcher <pthatcher@google.com> wrote:

Are these certificates DTLS-specific?  If so, then perhaps RTCDtlsCertificate would be a better name.  If not, then perhaps a name other than "RTCDtlsFingerprint" would make more sense for the fingerprint.  If so, having generateCertificate on DtlsTransport would make more sense.  If not, generateCertificate on RTCCertificate would make more sense.

I agree this overlaps with the discussion Martin is having in the 1.0 group about certificates, especially when it comes to what is controllable.  I think we could start with what you have here and then add more controls as the discussion in 1.0 evolves.  

On Fri, Jul 3, 2015 at 1:35 PM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
Assuming that we do indeed want RTCCertificate to stand on its own within ORTC API (instead of having generateCertificate be a method of the RTCDtlsTransport as Peter suggested),  find below a draft of a new section 15 on Certificate Management.

There are still a number of open issues with the Certificate Management API in WebRTC 1.0, let alone with this draft.  As an example, a single keygenAlgorithm appears inadequate; other attributes aside from duration may be needed; it is unclear whether the intent is for RTCCertificate to be used a universal interface to certificates, etc.

However, given the potential impact of the Certificate Management API (assuming we really do want to mandate it in ORTC), it seemed like a good idea to have a discussion about those issues ASAP.  

15. Certificate Management

NOTE

This section of the ORTC API specification depends on the WebRTC 1.0 Certificate Management API, and needs to be synchronized once it is updated.

15.1 Overview

The RTCCertificate interface enables the certificates used by an RTCDtlsTransport to be provided in the constructor. This makes it possible to support forking, where the offerer will create multiple RTCDtlsTransport objects using the same local certificate and fingerprint.

15.2 RTCCertificate Interface

The Certificate API is described below.

interface RTCCertificate {
    readonly    attribute Date               expires;
    readonly    attribute RTCDtlsFingerprint fingerprint;
    static Promise<RTCCertificate> generateCertificate (AlgorithmIdentifier keygenAlgorithm);
};
15.2.1 Attributes

expires of type Date, readonly

The expires attribute indicates the date and time after which the certificate will be considered invalid by the browser. After this time, attempts to construct an RTCDtlsTransport using this certificate fail.

Note that this value might not be reflected in a notAfter parameter in the certificate itself.

fingerprint of type RTCDtlsFingerprint, readonly

The fingerprint of the certificate.

15.2.2 Methods

generateCertificate, static

The generateCertificate function causes the user agent to create and store an X.509 certificate [X509V3] and corresponding private key. A handle to information is provided in the form of the RTCCertificate interface. The returned RTCCertificate can be used to control the certificate that is offered in the DTLS sessions established by RTCDtlsTransport.

The keygenAlgorithm argument is used to control how the private key associated with the certificate is generated. The keygenAlgorithm argument uses the WebCrypto [WebCryptoAPI] AlgorithmIdentifier type. The keygenAlgorithm value MUST be a valid argument to Crypto.subtle.generateKey; that is, the value MUST produce a non-error result when normalized according to the WebCrypto algorithm normalization process [WebCryptoAPI] with an operation name of generateKey and a [[supportedAlgorithms]] value specific to production of certificates for RTCDtlsTransport.

Signatures produced by the generated key are used to authenticate the DTLS connection. The identified algorithm (as identified by the name of the normalized AlgorithmIdentifier) MUST be an asymmetric algorithm that can be used to produce a signature.

The certificate produced by this process also contains a signature. The validity of this signature is only relevant for compatibility reasons. Only the public key and the resulting certificate fingerprint are used by RTCDtlsTransport, but it is more likely that a certificate will be accepted if the certificate is well formed. The browser selects the algorithm used to sign the certificate; a browser SHOULD select SHA-256 [FIPS-180-3] if a hash algorithm is needed.

The resulting certificate MUST NOT include information that can be linked to a user or user agent. Randomized values for distinguished name and serial number SHOULD be used.

A user agent MUST reject a call to generateCertificate() with a DOMError of type "InvalidAccessError" if the keygenAlgorithm parameter identifies an algorithm that the user agent cannot or will not use to generate a certificate for RTCDtlsTransport.

The following values MUST be supported by a user agent: { name: "RSASSA-PKCS1-v1_5", modulusLength: 2048, publicExponent: 65537 }, and { name: "ECDSA", namedCurve: "P-256" }.

It is expected that a user agent will have a small or even fixed set of values that it will accept.

Parameter

Type

Nullable

Optional

Description

keygenAlgorithm

AlgorithmIdentifier

✘

✘

Return type: Promise<RTCCertificate>