Re: Issue 195: Certificate Management

Here is a draft of a new section 15 relating to the Certificate Management API, which was introduced into the WebRTC 1.0 API as of the last Editor's draft.  This assumes that we want a new RTCCertificate object, instead of adding a createCertificate() method to the DtlsTransport object (although the text could easily be modified to do that instead if the CG prefers that approach).

Note: I believe that reuse of AlgorithmIdentifier from WebCrypto is problematic, because it was not intended for use in WEBRTC DtlsTransport certificate generation.

================================

15. Certificate Management

NOTE
This section of the ORTC API specification depends on the WebRTC 1.0 Certificate Management API, which was recently introduced and is still a work-in-progress.

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>

Received on Thursday, 27 August 2015 17:05:57 UTC