[Bug 25269] Add a container-independent initialization data type for providing a list of key IDs to createSession()

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

--- Comment #9 from David Dorwin <ddorwin@google.com> ---
(In reply to Joe Steele from comment #8)
> (In reply to David Dorwin from comment #7)
> > (In reply to Joe Steele from comment #6)
> > > The
> > > information about how to use the key ID to decrypt content is contained
> > > within the PSSH. If the PSSH is not present, in general the DRM does not
> > > have enough information to retrieve the key needed to decrypt the content.
> > 
> > Are you referring to information related to key chaining and/or domain keys?
> > CENC specifies AES-CTR mode, so it's unclear what else is necessary to map a
> > key ID to a decryption key and apply it.
> 
> This is simple key acquisition, no chaining required. This has nothing to do
> with the encryption mode. This is about giving the CDM the information it
> requires to retrieve the key. I can give you two examples of information
> that might be required - the URL of the license server and the certificate
> used to encrypt for it. 

An application using the mechanism proposed in this bug would likely know the
URL and certificate. Bug 25201 proposes an interoperable way to provide such a
certificate.

> > 
> > I wouldn't say that the key ID is not enough in general. There are plenty of
> > services in production where it is.
> 
> It would be more precise for me to say that there are significant services
> in production for which this does not hold true. 
> 
> I agree - there are some DRMs that do not require more than the key ID
> because they manage everything on the server side. There are certainly
> services that rely on those specific DRMs. 
> 
> However the reason the CENC spec is written the way it is, is that for many
> DRMs the key ID alone is not enough to specify how to retrieve the key.

As discussed in bug 17673 (starting at #15), relying on proprietary
functionality in the PSSH box is problematic for EME's interop story. EME
relies on commonly encrypted files, but that doesn't mean it uses or supports
every possible feature of an external spec.

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

Received on Monday, 7 April 2014 20:36:42 UTC