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

On Aug 15, 2013, at 10:52 , Mark Watson <watsonm@netflix.com> wrote:

> 
> 
> 
> 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.

That's one way it's done, sure (and common; you prove to someone that your implementation meets requirements, and then you exchange some secret).  I think Open Media Commons used signed code.

> 
> 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.
> 
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 15 August 2013 18:00:25 UTC