[Bug 25201] New: Add ability to preemptively provide a server certificate

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25201

            Bug ID: 25201
           Summary: Add ability to preemptively provide a server
                    certificate
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Encrypted Media Extensions
          Assignee: adrianba@microsoft.com
          Reporter: ddorwin@google.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

As discussed in bug 24025 and the Privacy Considerations section of the spec,
server certificates can be used to encrypt communication between the CDM and
license server, ensuring identifiers are protected at all times.

While the CDM could ask for a certificate in a message (in place of the license
request), this would require an extra round trip. Therefore, applications
should be able choose to proactively provide such a certificate before calling
createSession() (to reduce the latency).

Key systems that use such certificates should also support the additional round
trip model above to simplify interoperability for applications that are not
designed to provide certificates to specific key systems.

Since such a certificate is useful for all sessions and traffic and is unlikely
to vary for a given application and key system combination, it makes sense for
this to be a property of the MediaKeys object. There should be no need for an
application to later retrieve the certificate, so a setter method is
sufficient.

My proposal is to add the following to MediaKeys:
void setServerCertificate(Uint8Array serverCertificate);

The first step in the algorithm would be:
If the content decryption module corresponding to the keySystem attribute does
not support  server certificates, throw a NOT_SUPPORTED_ERR exception and abort
these steps.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 29 March 2014 01:18:28 UTC