Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Allow for long-lived key encryption keys (aka "master" keys) to increase performance #53
One of the use cases discussed in #41 was the inclusion of title keys in the media Initialization Data that are encrypted using some "master key" that the CDM previously acquired. The primary benefit of a system that provides title keys this way is to improve performance by reducing the number of key requests. However to realize this performance benefit, the CDM must be allowed to store keys in a location not dependent on a particular session. This is required because otherwise a request for a "master key" would be required for every session and you are just replacing one type of key request with another. Assuming that #41 is resolved, the usage of this feature can be invisible to the application.
Here are the main changes this would introduce:
Here are some of the spec changes I envision (there are more I am sure):
We could add support to the Common PSSH for this feature, but I will leave that for another bug.
Responding to some discussion in the telco today --
@jdsmith brought up the question of whether these keys should be downloaded in persistent sessions to allow the app to better manage them.
I do not believe master keys should be required to be downloaded in persistent sessions because I don't believe the current session mechanism is capable enough to handle managing their lifetime. I agree that allowing the app to manage title keys is a good thing. However allowing the app to manage all keys (e.g. master keys) would expose a lot of not-easily-interoperable details for not much benefit.
Let me turn the question around -- under what conditions do we believe an app will need to manage these keys? And what type of management are we talking about?
The one use case I can think of is when a user wants to remove their footprint from the browser. In that case, rather than a discovery mechanism, I think a "clean slate" API which removes all persistent data stored by the CDM at once would be more appropriate.
referenced this issue
Aug 10, 2015
referenced this issue
Oct 7, 2015
As a clarification, let me point out that this proposal is specifically talking about key encryption keys which are cached not key encryption keys which are baked into a CDM or key encryption keys that are acquired during the lifetime of a particular MediaKeys instance.