- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 5 Mar 2012 11:17:13 +0200
- 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 hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Monday, 5 March 2012 09:17:41 UTC