[Bug 17199] Provide examples for and get feedback on Key Release

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199

--- Comment #16 from Mark Watson <watsonm@netflix.com> ---
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > Comment on attachment 1313 [details]
> > > Proposal for key release text
> > > 
> > > What happens if the CDM crashes before it has released a certain key?
> > 
> > The CDM implementation needs to handle non-graceful shutdown. One
> > implementation would be for the CDM to regularly write to secure persistent
> > store a list of the current sessions with known keys. At any subsequent time
> > (e.g. after restarting after a crash), this persisted list can be compared
> > with the actual current sessions with known keys. Any differences are
> > sessions for which the keys are no longer known and require to have key
> > release message sent and acked. So these session records would then be added
> > to a different list of unacknowledged released sessions.
> > 
> > Of course you have some rare corner cases where crashes happen during the
> > update of the persistent store itself.
> 
> What assurance/benefit does this complication provide over the CDM promising
> to honor key expiry times communicated by the server when in the streaming
> case the expiry times could be short? If the server doesn't trust the CDM to
> honor expiry times, why would it trust key release attestations?

Good question. We can compare with a solution where keys have short expiry
times and require repeated renewal in order for streaming to continue. The
difference is that expiring keys require frequent license server interaction
for streaming to continue, whereas the approach with key release messages
requires license server interaction only at stream start and end.

Consequently, to achieve a given service availability, license server
availability needs to be orders of magnitude higher with the expiring license
approach compared to the key release approach.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 18 March 2013 15:27:31 UTC