Re: {minutes} HTML WG media telecon 2013-08-13 - EME status and bugs discussion

On Thu, Aug 15, 2013 at 10:33 AM, David Singer <singer@apple.com> wrote:

>
> On Aug 14, 2013, at 16:33 , Robert O'Callahan <robert@ocallahan.org>
> wrote:
>
> > On Wed, Aug 14, 2013 at 4:11 AM, Joe Steele <steele@adobe.com> wrote:
> > johnsim: the issue here goes back to the definition of openness we are
> exploring
> > ... seems like it may only be acheivable depending on how you define
> opennesss
> > ... if you require the internal functioning of the CDM to be published,
> that is overly intrusive
> > ... like to know more about the actual requirements, what problem it
> solves
> > paulc: more compatibility with open source
> > johnsim: in the sense that someone could implement the CDM without
> working with the proprietary key system provider
> > ... could provide a bogus DRM that would not enforce restrictions - not
> reliable
> > markw: that question is exactly what I asked Robert before, he gave a
> detailed answer with information about security and privacy reviews
> > ... think it is reasonable to ask, it is up to the DRMs to determine
> whether this would compromise the DRM system
> >
> > Thanks Mark.
> >
> > The proposal in the bug explicitly does not require publication of all
> the information required to reimplement a CDM --- since that obviously
> wouldn't fly. The proposal in the bug is to publish all information about
> the operation of the CDM except for the values of cryptographic keys. This
> matches the "best practices" of modern cryptography, in which the security
> of a system depends only on keeping secret keys secret, not on keeping
> secret how the system works.
>
> There will usually also be something about the operation of the DRM that
> enables the client to demonstrate that it's a respectable implementation --
> not one that was designed, for example, to transcode to clear media and
> save the result.
>

This is really just the "secret keys" that Robert refers to. Embedded in
the DRM client is a secret key unique to that implementation or even that
device which is hard to discover. That same key is configured in the
license servers [*]. The owner of the license server only configures keys
that he knows are embedded in clients that meet their robustness rules and
clients can use that key to prove they are compliant implementations.

Given the information that Robert proposes be disclosed, you *could* build
your own version of that DRM client and it would work with *your* license
servers or with anyones license servers who configured the secret keys that
*you* embedded. You'd have a parallel DRM system disjoint from the original
DRM vendors's system. Of course there are also IPR issues ...

...Mark

[*] This is a simplification, of course, and you can imagine any number
of public-key or real-time systems which support an ecosystem of license
servers operated by service providers where you don't need to configure
every client into every license server and instead rely on some central
authority, usually the DRM vendor. But the basic principle holds.


> >
> > Discussion in the bug answers questions recorded in the minutes ---
> please read it.
> >
> > Rather than have group members speculate about the acceptability of
> these requirements to CDM vendors, we should elicit direct public feedback
> from CDM vendors on whether they can accept these requirements --- and if
> not, why not.
> >
> > Rob
> > --
> > Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny
>  eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha
> iids  teoa stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e
>  tfaokreg iyvoeunr, 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea
> lmka'n?  gBoutt  uIp  waanndt  wyeonut  thoo mken.o w
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
>
>