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

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:
http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#initialization-data.
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/
>