Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

On 3/7/12 12:31 AM, Henri Sivonen wrote:
> On Mon, Mar 5, 2012 at 7:55 PM, Mark Watson<watsonm@netflix.com>  wrote:
>> >
>> >  On Mar 5, 2012, at 3:52 AM, Henri Sivonen wrote:
>> >
>>> >>  On Sat, Mar 3, 2012 at 4:19 AM, Mark Watson<watsonm@netflix.com>  wrote:
>>>> >>>  On Mar 2, 2012, at 1:22 AM, Henri Sivonen wrote:
>>> >>
>>> >>  You said in another email that it's a requirement that mp4 files be
>>> >>  encrypted using ISO Common Encryption. That seems to mean AES-CTR
>>> >>  inside the container. So the message that ultimately needs to be
>>> >>  transferred is the AES-CTR key. It seems to me it would be possible to
>>> >>  define one message format for transferring the AES-CTR key to the CDM
>>> >>  and have the protection systems adapt to consume this one HTML media
>>> >>  key messaging format. I don't see why a priori HTML would need to
>>> >>  adapt to multiple back ends that implement ISO Common Encryption
>>> >>  instead of the back ends adapting to a standard message format.
>> >
>> >  I think the reason is IPR. Yes, one could easily define such a message format that sends the key in such a way that only the CDM can see it. IANAL, but I'm told that you would then be in an IPR minefield.
> It's troubling to see spec proposals go into the mode of declaring
> defeat in face of patents from the get-go without even trying to
> develop an RF solution under the W3C PP.
>
Well, here's a recent post I saw from the internet, for a first crack at 
some hardware based key jangling:
http://blog.habets.pp.se/2012/02/TPM-backed-SSL

Not as impressive as the on-chip work of some of the new "HD"-capable 
devices that run it all on hardware.

-Charles

Received on Wednesday, 7 March 2012 09:12:29 UTC