W3C home > Mailing lists > Public > public-html@w3.org > March 2012

Re: Encrypted Media proposal: Summary of the discussion so far

From: David Dorwin <ddorwin@google.com>
Date: Mon, 12 Mar 2012 12:08:22 -0700
Message-ID: <CAHD2rsij2HBNJmF_TC1KK6jLV=LiALyasNWMEsx4GfH62yTJeg@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: public-html@w3.org
On Mon, Mar 12, 2012 at 12:29 AM, Henri Sivonen <hsivonen@iki.fi> wrote:

> On Fri, Mar 9, 2012 at 8:11 PM, David Dorwin <ddorwin@google.com> wrote:
> > On Fri, Mar 9, 2012 at 2:59 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> >> Are there disclosed specs / design documents explaining
> >>  1) how you plan to encrypt WebM
> >>  2) what kind of key passing messages you plan to use
> >>  3) if the CDM includes secrets (private key or secret algorithms),
> >> how you plan to share those secrets with other vendors
> >> ?
> >>
> > We're still early in the process. #1 will be handled separately by the
> WebM
> > Project. #2 and #3 seem CDM-specific, so I'm not sure what you're asking.
> Are there publicly-disclosed specs or design documents for any of
> this? (I failed to see recent threads on the WebM mailing list
> relevant to #1.)

This will be publicly available as soon as it's ready.

> For #2, what I'm asking is this: You will need to have some format and
> semantics for the initData parameter of generateKeyRequest() and for
> the key and initData parameters of addKey(). What format and semantics
> do you plan to use for these? In particular, do you believe that what
> you have chosen here is royalty-free? If you believe you have found a
> royalty-free (but not clear key) initialization procedure, are you
> willing to standardize it under the W3C Patent Policy?

initData is container-specific, not CDM-specific:
I expect that ISO Common Encryption, WebM, etc. will define the format.

key, which will often be a license, is CDM-specific. The format and
semantics will be up to the CDM providers. I don't object to standardizing
it, but I'm not sure of the value since it is likely encrypted.

> For #3 what I'm asking is this: Presumably, your CDM will have an
> embedded secret so that only a piece of software embedding that secret
> can successfully use the data passed to addKey(). I'd expect this
> secret to be at minimum a private key for an asymmetric encryption
> algorithm. Even if the behavior of your CDM was published except for
> this secret, another vendor wouldn't be able to develop an independent
> implementation that works with a site that targets Chrome unless the
> site is changed to cater to the secret embedded in another browser in
> addition to catering to the secret embedded in Chrome. Are you
> planning to share the secret part of your CDM with other browser
> vendors in order to enable interoperability and to avoid lock-in? (In
> other words, if the secret is just an RSA private key, are you willing
> to share Chrome's private key with other browsers, such as Firefox and
> Opera?) If so, under what terms?

The proposal defers the secret(s) to the CDM. Sharing the secret(s) is just
one possible way for a CDM vendor to support multiple browsers.

> --
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
Received on Monday, 12 March 2012 19:09:15 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:50 UTC