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

On Jan 17, 2013, at 10:37 AM, David Dorwin wrote:



On Thu, Jan 17, 2013 at 9:29 AM, Mark Watson <watsonm@netflix.com<mailto: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<mailto: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<mailto: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<mailto: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.

Ok, so I may have mis-understood your proposal.


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.

It seems we can't find a set of generic capabilities which make secure proof of key release just another CDM behavior like heartbeat, so the path we were on doesn't seem to be working.

So, I'd suggest we keep the secure proof of key release section as I proposed, but cut it down so that it no longer duplicates the createSession algorithm text (now possible with your suggestion). I'll update that proposal today.

…Mark


…Mark