Most likely this bug boils down to defining the shape of PSSH boxes for ClearKey and defining the ClearKey identifier for CENC.

We need to wait for bug 17673 to be finished before we can complete this.

I propose this format.

SystemID value: 58147ec8-0423-4659-92e6-f52c5ce8c3cc (represented here in network byte order)
Contents of Data: 128-bit key ID, with no other information

Example in C-encoded hex, for a KID having the ASCII value "ClearKeyTestKID\0":

static const char* kClearKeyPSSH = {
    0x00, 0x00, 0x00, 0x30, 0x70, 0x73, 0x73, 0x68, // BMFF box header
    0x00, 0x00, 0x00, 0x00,                         // Full box header
    0x58, 0x14, 0x7e, 0xc8, 0x04, 0x23, 0x46, 0x59, // SystemID
    0x92, 0xe6, 0xf5, 0x2c, 0x5c, 0xe8, 0xc3, 0xcc,
    0x00, 0x00, 0x00, 0x10,                         // Size of Data (KID)
    0x43, 0x6c, 0x65, 0x61, 0x72, 0x4b, 0x65, 0x79, // Data (KID):
    0x54, 0x65, 0x73, 0x74, 0x4b, 0x49, 0x44, 0x00  // "ClearKeyTestKID\0"
};

I like this simple format for the Data portion of the PSSH box. I filed bug 24419 to define a license request format for Clear Key so apps don't need to parse a PSSH box.

One question for the group: Does it make sense to support specifying multiple key IDs in the PSSH or should we just rely on the server to translate one to N (i.e audio and video keys)?
I believe some commercial protection systems do former; are there any that do the latter? The Clear Key license format will support multiple key ID-key pairs. Clear Key and this PSSH format should be capable of anything (reasonable within the context of EME/browsers) that commercial key systems support.


This thread questioning the need for system-specific PSSH boxes includes some analysis of some existing PSSH formats:
* http://lists.w3.org/Archives/Public/public-html-media/2013May/0017.html
* http://lists.w3.org/Archives/Public/public-html-media/2013May/0018.html
* http://lists.w3.org/Archives/Public/public-html-media/2013May/0025.html

I think the generic PSSH format should support multiple key ids.

Also, we have found it very useful to include a hash or MAC of the content key, such that the client can easily determine if it has the right key, when it has it.

I can provide a concrete proposal if people think this is a good idea.

I have concerns about adding/requiring a hash. Some system designs might wish to generate the PSSH in an area that does not have access to the actual key. This might be especially true if the PSSH is generated on the frontend or in the application.

It's also unclear how the CDM would use the hash. There is nothing in EME that requires that the key(s) be provided in the next response or all at once, though I guess some key systems might enforce that. There could also be ambiguity/complexity in dealing with cases involving multiple keys (request or license), especially when the number of keys in the license do not match the number of key IDs/hashes in the license request.


Assigning to Mark to make a proposal.

My proposal, in outline, would be that the PSSH box contain
- one or more 16-byte Key Ids
- for each Key Id, optionally, a 16-byte MAC of the Key Id, calculated as the HMAC-SHA256 of the Key Id using the Content Key as the key for the HMAC calculation

The purpose of the MAC is to enable the CDM to validate the key that it receives for a given Key Id immediately that it receives it, before using it for decryption.

The MAC can be optional, so that service providers can decide whether providing it (with the consequence that the content keys must be available to the packaging system that generated this box) is worthwhile. I would expect, though, that the PSSH is usually constructed when the file is encrypted - since the form of the encryption is very ISO BMFF-specific - and s the encryption key(s) would be available.

I think you mean a 32 byte MAC of the KeyID right? 

This looks like a good format. And many (most?) OTT providers should be able to generate this either at packaging time or at license generation time without trouble.

(In reply to Mark Watson from comment #6)
> My proposal, in outline, would be that the PSSH box contain
> - one or more 16-byte Key Ids
> - for each Key Id, optionally, a 16-byte MAC of the Key Id, calculated as
> the HMAC-SHA256 of the Key Id using the Content Key as the key for the HMAC
> calculation

This sounds fine. The question is how do we specify the count (easier) and whether to expect the MAC.

> I would
> expect, though, that the PSSH is usually constructed when the file is
> encrypted - since the form of the encryption is very ISO BMFF-specific - and
> s the encryption key(s) would be available.

To clarify, the first paragraph of comment #5 was referring to also being able to generate the PSSH to provide to createSession(). I agree that the encryption key should always be available during packaging.


(In reply to Joe Steele from comment #7)
> This looks like a good format. And many (most?) OTT providers should be able
> to generate this either at packaging time or at license generation time
> without trouble.

Yes, but it's not needed at license generation time - the license contains the key but not the Initialization Data. On the other hand, an application might want to generate valid Initalization Data at license request generation time (createSession()).

(In reply to David Dorwin from comment #8)
> (In reply to Joe Steele from comment #7)
> > This looks like a good format. And many (most?) OTT providers should be able
> > to generate this either at packaging time or at license generation time
> > without trouble.
> 
> Yes, but it's not needed at license generation time - the license contains
> the key but not the Initialization Data. On the other hand, an application
> might want to generate valid Initalization Data at license request
> generation time (createSession()).

You are right. I guess I was thinking of generating it on the server as well to confirm the key prior to sending to the client. But I don't believe we send this MAC in the key request for ClearKey do we? So it must be validated on the client side.

(In reply to Joe Steele from comment #9)
> (In reply to David Dorwin from comment #8)
> > (In reply to Joe Steele from comment #7)
> > > This looks like a good format. And many (most?) OTT providers should be able
> > > to generate this either at packaging time or at license generation time
> > > without trouble.
> > 
> > Yes, but it's not needed at license generation time - the license contains
> > the key but not the Initialization Data. On the other hand, an application
> > might want to generate valid Initalization Data at license request
> > generation time (createSession()).
> 
> You are right. I guess I was thinking of generating it on the server as well
> to confirm the key prior to sending to the client. But I don't believe we
> send this MAC in the key request for ClearKey do we? So it must be validated
> on the client side.

My understanding is that the main purpose is for the CDM to use the MAC to verify the contents of the license are what it needs. It's still unclear how the CDM would do this and what it would report should the verification fail.

Clear Key does not use the MAC. This would only apply to other key systems that support this common PSSH format.

For the question of what to do if the MAC doesn't validate, this should be the same as any other fatal problem with the license. Don't we just fire a keyerror event ?

I think a key error should be fired in this case. We don't have a good name right now - but I think it would be good to distinguish this from an error resulting from a failed decryption. This would aid debugging. 

For example:
  MEDIA_KEY_ERROR_BAD_KEY means the MAC did not validate (for this key system)
  MEDIA_KEY_ERROR_BAD_DECRYPT means the content was garbled somehow

Concretely, we could use the new version of the PSSH box, defined as follows:

aligned(8) class ProtectionSystemSpecificHeaderBox extends FullBox(‘pssh’, version, flags=0) 
{  
	unsigned int(8)[16]   SystemID;
	if (version > 0) 
 	{ 
  		unsigned int(32)    KID_count;   
  		{ 
   			unsigned int(8)[16]  KID; 
  		} [KID_count]; 
 	} 
 	unsigned int(32)    DataSize;  
 	unsigned int(8)[DataSize] Data;  
}

For the clear-key case, the Data would be defined to contain

{
	unsigned int(8)[16]  keyMac;
} [KID_count];

or Data may be empty if the MACs are not provided.

For each key,

keyMac = HMAC-SHA256( CK, KID ), where CK is the content key with key id KID.

(In reply to Mark Watson from comment #13)
The KID_count and KID portion apparently come from a draft of the second edition of the CENC spec. This is a dependency we would have to consider. Also, it's unclear if this is actually the intended usage for these values.

(In reply to David Dorwin from comment #14)
> (In reply to Mark Watson from comment #13)
> The KID_count and KID portion apparently come from a draft of the second
> edition of the CENC spec. This is a dependency we would have to consider.
> Also, it's unclear if this is actually the intended usage for these values.

Per an email discussion with Kilroy Hughes, the intended usage of the KID_count and KIDs is to indicate in a DRM-agnostic way the KIDs of the keys that are described by this PSSH. This enables DRM-independent de- or re-fragmentation of the file.

The same KIDs would usually also be specified in the DRM-specific contents of the PSSH box.

(In reply to Mark Watson from comment #15)
> (In reply to David Dorwin from comment #14)
> > (In reply to Mark Watson from comment #13)
> > The KID_count and KID portion apparently come from a draft of the second
> > edition of the CENC spec. This is a dependency we would have to consider.
> > Also, it's unclear if this is actually the intended usage for these values.
> 
> Per an email discussion with Kilroy Hughes, the intended usage of the
> KID_count and KIDs is to indicate in a DRM-agnostic way the KIDs of the keys
> that are described by this PSSH. This enables DRM-independent de- or
> re-fragmentation of the file.
> 
> The same KIDs would usually also be specified in the DRM-specific contents
> of the PSSH box.

This is inline with Adobe's usage of KID and KID_count.

Using the KID array sounds fine. I think we should hold off on defining the Data until we have more implementation experience. That will allow Clear Key-compatible content to be created without worrying about later incompatibilities.

Mark, will you add this modified proposal to https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/cenc-format.html ?

The proposed specification is as follows:

SystemID: 1077efec-c0b2-4d02-ace3-3c1e52e2fb4b.
version: 1 or higher (as appropriate)
KID & KID_count: the key IDs represented by the PSSH box (i.e. those used by the moov/moof.
Data and DataSize: Reserved for future use/specification. DataSize must be 0 for now.

The text should also note that Clear Key, which is defined in the main spec, uses this SystemID and format.

Implemented in https://dvcs.w3.org/hg/html-media/rev/3d777e556c04

I added an example PSSH box in https://dvcs.w3.org/hg/html-media/rev/f1578a4341e7.

I implemented Postel's rule for the Data field of the PSSH in https://dvcs.w3.org/hg/html-media/rev/b7426450ef2b