Re: [EME] Updated proposal for secure proof of key release

On Thu, Jan 17, 2013 at 9:29 AM, Mark Watson <watsonm@netflix.com> wrote:

> On Jan 17, 2013, at 9:14 AM, David Dorwin wrote:
>
> On Wed, Jan 16, 2013 at 4:57 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>> On Jan 16, 2013, at 3:40 PM, David Dorwin wrote:
>>
>> On Wed, Jan 16, 2013 at 1:45 PM, Mark Watson <watsonm@netflix.com> wrote:
>>
>>> On Jan 16, 2013, at 12:20 PM, David Dorwin wrote:
>>>
>> On Tue, Jan 15, 2013 at 9:36 AM, Mark Watson <watsonm@netflix.com> wrote:
>>>>
>>>  New FAQ and answer:
>>>>
>>>>  "Is secure management of the entire key lifecycle supported ?
>>>>
>>>>  Yes.
>>>>
>>>>  If a CDM implements the capability to provide a secure proof of key
>>>> destruction (i.e. a signed attestation from the CDM that a given key has
>>>> been destroyed), this capability may be exposed by generating a keymessage
>>>> event when the key is destroyed, containing this attestation. The CDM
>>>> should persist a record of the session and the key destruction, in case the
>>>> keymessage cannot be delivered for any reason, for example network loss or
>>>> inability to deliver messages during page close. This persisted record
>>>> should be removed when an acknowledgement of the secure proof of key
>>>> release is received through an update() method. MediaKeySessions associated
>>>> with such persisted sessions could be retrieved at a later time (e.g. after
>>>> page unload and later page load) using the createSession() method with null
>>>> type and initData which implicitly match any persisted session for the page
>>>> origin."
>>>>
>>>
>>>  I think null type is a strong and potentially generally useful value
>>> that should not be dedicated to key release
>>>
>>>
>>>  I'm not suggesting it's dedicated to key release. It would match any
>>> persisted session, whatever state that is in.
>>>
>>
>>  Okay. My statement still applies to "persisted session". I think the
>> use of "null" would have to really stand out as "of course, that makes
>> sense."
>> As it stands, we allow null but don't really have a use case and it's
>> basically there for key system-specific use. Maybe we should make it a
>> required parameter. I filed
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20691.
>>
>>>
>>>   nor have its behavior defined in a FAQ or other non-normative text.
>>>
>>>
>>>  Actually it should be defined normatively that "null" matches
>>> everything, rather than nothing.
>>>
>>
>>  |type| is intended to tell the CDM how to interpret |initData|. I'm not
>> sure "everything" makes sense in this context.
>>
>>
>>   I agree 'null' isn't ideal, but I would still like to have a defined
>> way to retrieve an arbitrary pre-existing session, since that's the missing
>> generic capability
>>
>
>  I'm not sure we need a way to "retrieve an arbitrary pre-existing
> session". That is a really wide scope for which we can't possibly foresee
> all the scenarios it might affect. Even type = "persisted" might be too
> generic. Some key system might have another reason to persist sessions and
> a defined generic capability could cause ambiguity for apps. I think the
> class of sessions you really want to be returned is "persisted key
> releases" or "persisted inactive/closed sessions".
>
>
>>  needed to give proof of key release the same status as heartbeat etc.
>>
>
>  Can you clarify?
>
>
>  I thought your proposal was that we would tweak/modify the existing
> general purpose text so that secure proof of key release became something
> which could be implemented by CDMs without special CDM-specific logic in
> the client application - in the same way as heartbeat can. This was the
> justification for removing the secure proof of key release section.
>

My proposal was to tweak/modify the existing text so that it was compatible
with and did no preclude secure proof of key release. This has mainly
involved fixing wording that is unintentionally restrictive.

>
>  To do that, we need sufficient generic capabilities in the main text
> that the implementation of secure proof of key release doesn't seem like a
> hack. Having the CDM decide to send messages and expect response at the
> time of its choice (as for heartbeat) seems completely natural. But
> expecting applications to know a CDM-specific incantation to retrieve
> persisted sessions seems like a hack.
>
> I agree, heartbeat is much more natural and easier to support. Key release
is much more complex, and it's probably not possible (or appropriate) for
this spec to define everything necessary for interoperable and equivalent
implementations of key release to be developed from it alone. I think we
should ensure that it is possible to implement key release within the spec.
However, the details Netflix-approved key release implementations will
probably require a separate detailed document, and the string value for
retrieving saved sessions is only a minor part of this.

>
>  I was planning to remove the heartbeat text since it just describes a
> policy and can be implemented entirely within a key system without adding
> any special logic to the application.
>
>
>  I think this illustrates why, with the existing text, secure proof of
> key release is different in character from heartbeat: it does require a
> normative capability to retrieve persistent sessions.
>
>  I don't think the "null" thing is particularly elegant. We could
> consider extending the createSession call with an enum for the kind of
> operation expected (new session, retrieve existing session etc.). If you
> think that a specific value is needed to retrieve "release key" sessions
> specifically, then I think we need to return to the model where we do
> include secure proof of key release as an explicit section. It could be a
> lot shorter now, as we don't need to duplicate the createSession()
> algorithm and I agree we could restrict it to describing how the persisted
> released key sessions are retrieved and not go into the other messaging of
> CDM procedure details.
>

I believe enums are discouraged in favor of strings because they are harder
to extend. That is what the existing proposal is - |type| is a string and
can be extended. By convention, "video/mp4", "video/webm", etc. are
commonly supported types, but they are not included in the spec. Likewise,
"keyrelease" could be another option.

>
>  …Mark
>