Re: EME support for CENC with AES-CBC?

A colleague just pointed out to me that I misread this amendment. The proposed amendment actually calls for a different scheme of ‘cbc1’ or ‘cbc2’ rather than ‘cenc’.
So this seems to not be supported based on the EME Initialization Data spec (https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/cenc-format.html#common-system). 
Am I reading that right?

Joe

On Jun 17, 2014, at 12:03 PM, Jerry Smith (WINDOWS) <jdsmith@microsoft.com> wrote:

> I understand that CBC is used on HLS content, and there is a move to support this for CENC.  To preserve the “common” aspect, there’s an implication that CENC decryption systems be capable of both CTR and CBC.
>  
> We might provide a way for sites to programmatically detect CDM support.  I’m not sure there’s a practical advantage unless websites can somehow maintain content in both encryption styles.
>  
> Jerry
>  
> From: David Dorwin [mailto:ddorwin@google.com] 
> Sent: Tuesday, June 17, 2014 11:32 AM
> To: Joe Steele
> Cc: Mark Watson; Jerry Smith (WINDOWS); <public-html-media@w3.org>
> Subject: Re: EME support for CENC with AES-CBC?
>  
> Some questions to help frame the discussion:
> Why would one use CBC instead of CTR? What would be gained that would justify the additional complexity to CDMs and/or adding another (non-)interoperability dimension?
>  
> Joe, why do you say the Apple CDM is an obvious candidate?
>  
> David
>  
> On Tue, Jun 17, 2014 at 9:25 AM, Joe Steele <steele@adobe.com> wrote:
> The obvious candidate CDM to support this would be the Apple CDM support announced at the recent WWDC. Although Adobe could support this as well. 
> Agreed about the “capabilities” field. This is a good area to think about.
>  
> Joe
>  
> On Jun 17, 2014, at 7:35 AM, Mark Watson <watsonm@netflix.com> wrote:
> 
> 
> I think this is a bridge to cross when we have a CDM that plans to support the new encryption mode. Seems like a prime candidate for the "capabilities" field proposed for isTypeSupported and that it could be addressed by defining a capability value in the byte stream format specification at some later date.
>  
> [Btw, we should probably define a high level format for the capability field so that it is possible to mix standardized capabilities with keysystem-specific ones].
>  
> ...Mark
>  
> 
> On Mon, Jun 16, 2014 at 6:03 PM, David Dorwin <ddorwin@google.com> wrote:
> Are you specifically interested in just CBC or is there something else in the amendment? (For what it's worth, it does not appear that amendment has been published.)
>  
> The ISO Common Encryption EME Stream Format and Initialization Data spec is based on ISO/IEC 23001-7:2012 the AES-128 CTR encryption it specifies.
>  
>  
> 
> On Mon, Jun 16, 2014 at 5:20 PM, Jerry Smith (WINDOWS) <jdsmith@microsoft.com> wrote:
> It would seem that when new encryption types are added to CENC, then these will need to be supported by CENC compatible CDMs.  If we agree on that, then the current model for IsTypeSupported() should be sufficient.
> 
> Jerry
> 
> -----Original Message-----
> From: Joe Steele [mailto:steele@adobe.com]
> Sent: Monday, June 16, 2014 1:57 PM
> To: <public-html-media@w3.org>
> Subject: EME support for CENC with AES-CBC?
> 
> I am curious whether this group intends to say anything about support for the AES-CBC encryption mode for ISOBMFF with CENC. I have been reviewing the amendments to the CENC spec, specifically "Part 7: Common encryption format for ISO base media file format, AMENDMENT 1: AES-CBC-128 and key rotation". I am wondering how CDMs should expect to handle this - or if it is called out via isTypeSupported().
> 
> This may have been discussed and I just cannot find the references to it.
> 
> Joe
>