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

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

From: Henri Sivonen <hsivonen@iki.fi>
Date: Mon, 5 Mar 2012 11:17:13 +0200
Message-ID: <CAJQvAueHGxUp61hab26NXSJ_GDja6rDz+W_L2i4REx-j4A46yw@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Christian Kaiser <kaiserc@google.com>, "<public-html@w3.org>" <public-html@w3.org>
On Mon, Mar 5, 2012 at 10:11 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> On Mon, Mar 5, 2012 at 2:57 AM, Mark Watson <watsonm@netflix.com> wrote:
>> This is exactly why encryption should be defined by container formats, not CDMs, so that CDMs *are* interchangeable. This is how we at Netflix are able to work with multiple CDMs but one set of media files using the ISO Common Encryption standard for mp4 files. It's a principle we could require in association with this proposal.
> This seem like an important constraint on CDM design. Why isn't this
> stated in the proposal?

I guess I should expand on that a bit:

If there is a requirement that at least when mp4 is used, the content
be encrypted using ISO Common Encryption (which appears to use AES-CTR
on the track level; correct me if I've misunderstood), why are you
proposing an open-ended way of communicating the track AES keys to a
CDM instead of proposing a Royalty-Free W3C standard for how the AES
keys reach the CDM in full detail?

Existing DRM systems are wider in scope than what's enough to satisfy
the streaming use case. Why do you presuppose integration with an
existing more complex system instead of proposing a specific system
scoped to streaming that would be minimally sufficient to bridge HTML
and ISO Common Encryption?

In particular, is there a specific need for more open-endedness than
the CDM having one private key at a given moment in time (could change
over time, since only streaming use case is relevant) and the site
encrypting the AES track keys using the public key corresponding to
the private key of the CDM? That is, why do you want more
unspecificity than keeping the CDM private key secret?

(Above "the" CDM means a box that can have independent implementations
but whose behavior is well specified.)

(Presumably, AES-CTR could be applied to Matroska, too, so the variety
of containers doesn't seem to be the cause why there couldn't be one
fully-specified delivery mechanism for the AES track key(s).)

Henri Sivonen
Received on Monday, 5 March 2012 09:17:41 UTC

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