[Bug 19788] What, if any, event should be fired when no key is available to decrypt the block?

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

--- Comment #3 from Steven Robertson <strobe@google.com> ---
(In reply to comment #0)
> For ISO BMFF/CENC^ and
> WebM, the needed keys can always be identified based on headers,

For CENC 2012, there's no specified coherence between PSSH boxes and tenc/senc
KIDs. It's certainly expected that the PSSH boxes contain the information
necessary to obtain the keys, but there is no guidance or guarantee offered
anywhere to this effect.

(The 2011 drafts of CENC extend 14496-12:2008, so this problem was much less
severe. There's still quite a bit of straw-man mischief one could get up to,
but there weren't that many legitimate reasons to do something twisted.
14496-12:2012 allows sample groups in fragments, which blows the barn doors
off.)

> 2) The key ID of the current block. This is easier to implement but 
> inconsistent with the Potentially Encrypted Stream Encountered algorithm 
> [2] and may not be useful for obtaining a key. This option is probably 
> better if we have a separate even name and/or fire it at different objects.

With my author hat on, I favor this. It solves at least one problem we have
already had to hack around (keeping content permissions and PSSH atoms in sync,
 with code to defend against drift present at every level) by allowing the
client or server to synthesize missing boxes on demand.

I also favor it from a spec point of view. Because of CENC's choice in making
PSSHs completely devoid of specified spatial/temporal correspondence with KIDs,
there really are two separate kinds of data at the format level. IMO, either we
should marshal these two and essentially amend the CENC spec via the
format-specific guidelines to require such a correspondence, or we should be
honest about the underlying discord and inform the client explicitly.

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

Received on Wednesday, 31 October 2012 07:10:49 UTC