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

On Fri, Mar 9, 2012 at 10:20 AM, Charles Pritchard <chuck@jumis.com> wrote:

> On Mar 9, 2012, at 10:11 AM, David Dorwin <ddorwin@google.com> wrote:
>
> On Fri, Mar 9, 2012 at 2:59 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>
>> On Fri, Mar 9, 2012 at 4:16 AM, David Dorwin <ddorwin@google.com> wrote:
>> > Chrome and YouTube plan to support encrypted WebM. Hopefully others
>> will as
>> > well.
>> > This option is not available in the current plugin-based environment.
>>
>> 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.
>
>
>
> CDM APIs are not that complex. Will someone shine a light on the basics? I
> mean it's just an encryption mechanism, public keys and send error messages
> and key requests.
>

Right, and maybe that's a source of confusion. I would expect the API to be
fairly simple and easy to document. It seems likely that such APIs will map
in some way to the APIs and algorithm in the proposal. For example,
licenses must be generated by and provided to the CDM and there must be a
method to provide the data to decrypt. Disclaimer: IANAL, I am not a
CDM implementer, and I can't speak for all CDM implementers.

>
> I understand CDM APIs may have some goodies in them, like activating
> phone-home features and so on; I don't think that's what is being asked.
>
> They're asking for the real information required for them to support
> existing CDMs. Some dll names and API headers.
>

As far as I know, this information doesn't exist yet since there aren't
currently any CDM implementations. While there are existing decryption
systems that perform some of the same functionality, it's not a given that
they will be used as-is with the same DLL names, APIs, etc. For one thing,
today the decryption functionality is often one part of a larger product or
stack.

>
> This information may be buried behind NDA regimes; we need to dig these
> critical, minimal bits of information out. This information is common to
> all CDMs, but in typical corporate process, valuable or not, everything is
> marked confidential.
>
> The vendors on this list work for the companies that produce these APIs.
> Surely you all can do a little bit of internal work to surface some
> documents to the public.
>
> They've been requested by other developers on this list. Forcing an NDA is
> not going to work.
>
> -Charles
>