W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > July 2012

[Bug 17682] New: Clear Key: Document how keys and key IDs are associated

From: <bugzilla@jessica.w3.org>
Date: Tue, 03 Jul 2012 21:08:07 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-17682-2486@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17682

           Summary: Clear Key: Document how keys and key IDs are
                    associated
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Encrypted Media Extensions
        AssignedTo: adrianba@microsoft.com
        ReportedBy: ddorwin@google.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org


Most Key Systems will define a "license" format, which defines the data in the
|key| parameter to addKey(). For Clear Key, the original plan was that |key|
would be exactly a decryption key.

Assuming an addKey() call can be associated with a specific initData value [1],
passing the exact decryption key as |key| works well for containers that use a
standard (i.e. non-opaque) format for initData and provide exactly one key ID
in each initData value. However, this will not work for containers that use
opaque formats, don't include a key ID in the actual initData, or can specify
multiple key IDs in an initData.

ISO BMFF using CENC is one of those [2]. In the CENC case, initData may be an
opaque blob and represent multiple keys. Thus, |key| could not be associated
with a specific key ID. (There is a related question in [2] related to
providing a PSSH that Clear Key can use.)

We either need to overcome the above issue or figure out an alternative way to
associate keys and key IDs for Clear Key. Ideally, Clear Key would work in the
same way as other key systems while remaining easy to use and understand. It
would also be nice if the Clear Key "license" format was consistent across
containers, though that is probably less important.

[1] In v0.1 of the proposal, the keyId can be specified in the |initData|
parameter. In the session object-based design, the |initData| parameter is
removed from addKey() (see also
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16549), but there is still a
direct correlation between addKey() and a single initData value.
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 3 July 2012 21:08:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2012 21:08:08 GMT