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

Hi Mark,

Comments and suggestions inline.

David

On Tue, Jan 15, 2013 at 9:36 AM, Mark Watson <watsonm@netflix.com> wrote:

>  Here are some additional changes which I think are required to implement
> David's alternative proposal for [1]
>
>  Address [2].
>
>  To Section 1.2.3 (SessionID):
> - To "If session IDs are supported, a new one will be generated each time
> createSession() successfully creates a MediaKeySession" add "for a new key
> session."
> - Change "although the CDM may retain them for longer periods" to
> "although the CDM may retain key sessions and their associated IDs for
> longer periods.".
> - Change "If secure proof of key release is supported each Session ID
> shall be unique within the origin." to "If the CDM retains key sessions
> across browsing sessions then each Session ID shall be unique within the
> origin."
>

I suggest changing  "If" to "When". If a CDM supported both retained and
unretained sessions, it does not *always* have to use unique IDs.


>  To David's createSession() proposal (see [1]):
> - To "Let key request be a key request generated by the CDM using
> initData, if provided" add "or null if no key request is generated."
>

So keymessage's message attribute can be null? That affects the event
definition (3.1) and seems undesirable. My proposed patch just says a
response is generated and assigned to the message attribute. That can be an
empty array in the key release case. Do we really need to support null or
specify *what* the value is?

- To "Note: cdm must not use any data, including media data, not provided
> via initDate" add "or already present in the cdm".
>

This is a note about creating the key request. Since one is not created in
your use case, I don't think this applies. More importantly, such a change
has much larger implications than key release. You can instead add "to
generate a key request" to the current text if you want.

 - Add to the above note: "The CDM may use pre-existing session data that
> matches the provided type and initData and that is not already associated
> with a MediaKeySession to initialize the session."
>

This seems pretty confusing. Is it necessary? Initializing a session is key
system-/CDM-specific and nothing prevents the scenario in the proposed text.
As mentioned above, the existing normative note is specifically related to
generation of a key request, so I definitely don't think they should be
folded together.


>  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 nor have its behavior defined in a
FAQ or other non-normative text. (Key systems may wish to use it for
something else.) Is there any reason not to use type = "keyrelease" from
your original proposal?

Minor note: "release" and "destruction" seem to be used interchangeably. Is
that intentional?


>
>  …Mark
>
>  [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199
> [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20622
>
>  On Jan 15, 2013, at 8:03 AM, Mark Watson wrote:
>
>  I think we also need to address
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20622
>
>  I will provide text for the FAQ answer.
>
>  As for requesting old sessions, I think we need to explicitly introduce
> the idea that CDMs may persist sessions and so createSession() may retrieve
> a preexisting session based on the type and initData. If the provided
> type/initData match multiple pre-existing sessions, then any one is
> returned (and so if they are both null, than any pre-existing session is
> returned). We should also ask that a keymessage is always sent (even if it
> might be null) when the session is created so that the user script has some
> indication when the sessionId is assigned.
>
>  …Mark
>
>  On Jan 14, 2013, at 6:19 PM, David Dorwin wrote:
>
>  Mark and I discussed this and agree that we should try to reuse as much
> of the base algorithms as possible. Mark would also like a consistent way
> to retrieve saved key sessions and a FAQ answer. Therefore, I propose the
> following tasks for resolution for this bug:
>
>    - Generalize createSession() algorithm so proposed 4.5.1 is covered by
>    it. There are a few statements that assume generation of licenses.
>    - Figure out where to document how to request old sessions, if
>    supported.
>    - Add a FAQ entry about how key release could be supported, similar to
>    the entry for heartbeat.
>
>
>  I’ve started working on the createSession() changes.
>
>  David
>
> On Fri, Jan 11, 2013 at 6:10 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>> Hi David,
>>
>>  Please see inline …
>>
>>   On Jan 11, 2013, at 10:07 AM, David Dorwin wrote:
>>
>>   Hi Mark,
>>
>>  The more I think about key release, the more I think it should not be
>> included in the spec.
>>
>>  Key management, policies, message protocol & structure, and key-system
>> or CDM-specific details have been intentionally left out of the spec. As an
>> example, even the key replacement algorithm is not specified. Key systems
>> are free to define protocols that include a variety of messages as long as
>> they fit within the defined APIs (primarily update() and keymessage).
>> Heartbeat, license renewal, key rotation, etc. can all be implemented
>> within the existing framework but are not included in the spec.
>>
>>  The key release proposal does not require altering the existing APIs or
>> the defined algorithms. It simply defines additional key management,
>> policy, parameter values, and messages, all of which are key
>> system-specific. As with the basic message flow, heartbeat, etc., I expect
>> that key systems will eventually converge on a set of best practices, but
>> these are not usually defined in a standards-track spec.
>>
>>
>>  The proposal does expose functionality at the API level and it's not
>> all just key-system specific.
>>
>>  Specifically, the concept of "sessions" and "sessionIds" is an API
>> concept, not a key-system-specific one. We say that anything that goes on
>> *within* a session is keysystem-specific. For example, the number of
>> message exchanges, when they occur in the session, what they do in terms of
>> keys etc. Heartbeat and key rotation are both examples of where - within a
>> session - some keysystem-specific magic can go on.
>>
>>  But the notion of a session itself is part of our API. We define how
>> you create them in a key-system-specific way. They're created from a
>> keysystem-independent object (the initData - although within it there may
>> be multiple keysystem-specific parts).
>>
>>  The key part of the secure proof of key release proposal is that it is
>> possible, from outside any session, to retrieve information related to
>> pre-existing sessions. We're adding a new way to interact with the CDM
>> outside the context of a session. I don't see how we could do that within
>> the existing API.
>>
>>
>>  Finally are there implementors and CDM providers that intend to support
>> this? Are there any content providers besides Netflix that intend to use it?
>>
>>
>>  Those are good questions. If the answer to the first one is no when we
>> get to the appropriate milestones in the specification work, we'll have to
>> pull this out. Just like anything else.
>>
>>  I'm not really empowered to speak on behalf of CDM implementors, but I
>> know that it's not pointless putting this in the specification now.
>>
>>  …Mark
>>
>>
>>  I do not think a Working Draft should include a feature where the
>> answer to the above questions is "no", especially when it adds non-trivial
>> complexity to implementations.
>>
>>  Regards,
>> David
>>
>> On Fri, Jan 11, 2013 at 9:10 AM, Mark Watson <watsonm@netflix.com> wrote:
>>
>>>  https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199
>>>
>>>  An updated proposal is attached.
>>>
>>>  I'd like to propose that we include this text in the First Public
>>> Working Draft.
>>>
>>>  [It need not be Section 4, as written, since this interrupts the flow
>>> of the rest of the document. I leave it to David to suggest the best place
>>> for it.]
>>>
>>>  …Mark
>>>
>>
>>
>>
>
>
>