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

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:
>
> I filed a couple bugs to track some minor issues with the existing
> spec. Comments inline.
>
> 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:
>>
>>  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.
>>
>>
>>  Ok.
>>
>>
>>
>>>  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?
>>
>>
>>  Empty array might work.
>>
>>  If we say that createSession() can retrieve an old session, and we say
>> this is generic, in support of "whatever capabilities CDMs want to offer",
>> not just specifically for secure proof of key release, then there is the
>> case of a session being retrieved in a state where no messages need to be
>> sent. For example a persisted session that already has an unexpired license
>> matching the supplied initData. But we need to generate some kind of event
>> to indicate when the sessionId has been assigned. A null message seemed
>> reasonable for this.
>>
>>   Sending keymessage to indicate "the CDM did what the app asked but has
> nothing to send to the server" seems useful and null/empty seems like a
> good normative definition for this. The only question is whether to use
> null or an empty array. If an app gets a null value, it may not handle an
> exception and stop working. If it gets an empty message and sends it to the
> server, it would seem things have a better chance of succeeding and the
> server can detect the issue. I'd like to hear from others that have more
> experience with these types of issues and API designs. In the end, it's a
> small issue. I opened https://www.w3.org/Bugs/Public/show_bug.cgi?id=20689 to
> track this discussion.
>
>>
>>   - 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.
>>
>>
>>  Hmm - I didn't read carefully enough where is refers to "key request".
>> If we're making this generic, shouldn't it just be "key message" ? In the
>> secure proof of key release case, where I retrieve a session related to a
>> deleted key, the message will be the secure proof of key release message.
>>
>
>  The purpose of this text was to enforce that the information about the
> media that is used to generate a key request be provided via the initData
> parameter. This doesn't necessarily apply to other uses of createSession().
> Thus, by adding "to generate a key request", we still enforce this for key
> requests while lifting the limitation for other uses.
>
>>
>>
>>   - 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.
>>
>>
>>  I think we need to say something too explain how you can retrieve old
>> sessions in a CDM-independent way.
>>
>>
>>
>>>  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 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.


> Do you have any other suggestions ?
>

>
>
>>   (Key systems may wish to use it for something else.) Is there any
>> reason not to use type = "keyrelease" from your original proposal?
>>
>>
>>  The original proposal was normative. I agree that we should try and
>> find a way where secure proof of key release is not specified normatively,
>> but can be built using the generic normative capabilities, in the same way
>> as heartbeat etc. But that means we need to define those generic normative
>> capabilities - specifically the retrieval of pre-existing sessions, which
>> is what I was trying to do above.
>>
>>  Certainly a CDM "can" provide any capability it wants - but I think we
>> need at least the basic concepts in the API in order for people to
>> understand how the capability makes sense in the context of the API and to
>> ensure some commonality across implementations. Otherwise it just looks
>> like secure proof of key release is a hack, not something which was
>> considered as a reasonable capability to be supported in the API.
>>
>>
>>  Minor note: "release" and "destruction" seem to be used
>> interchangeably. Is that intentional?
>>
>>
>>  No.
>>
>>
>>
>>>
>>>  …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
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>