Subject: [jose] Fwd: RESEND: JSON Web Key support for private and symmetric keys

From: Mark Watson <[email-masked]>
Date: Wed, 7 Nov 2012 21:45:28 +0000

> All, I was hoping to get this to you before your meeting, but get repeated delivery failures. One more try ...
> 
> Begin forwarded message:
> 
>> From: Mark Watson <[email-masked]>
>> Subject: JSON Web Key support for private and symmetric keys
>> Date: November 5, 2012 11:31:53 AM PST
>> To: <[email-masked]>
>> 
>> All,
>> 
>> First let me introduce myself. I work for Netflix and have been working on standardization of various components that we need for support of our service in pure HTML/Javascript. Specifically, the HTML Encrypted Media Extensions [1], Media Source Extension [1] and the WebCrypto API [3] in W3C (the latter to provide us the ability to implement a secure application protocol in Javascript).
>> 
>> At last week's W3C meeting in Lyon, two requirements came up that we believe could be met very well by the extension of JWK to support private and symmetric keys:
>> 
>> (1) Key wrap/unwrap in the WebCrypto API
>> 
>> The WebCrypto API can manage keys below the API boundary, avoiding the sharing of keying material with the Javascript environment. This has advantage in certain security models where the JS is less trusted than the UA.
>> 
>> We are working on the specification of key import/export functions including import/export of wrapped keys. Both these functions require an explicit binary representation of the key material to be defined. In the latter case it is required that not only the key itself is protected by the wrapping operation, but also attributes associated with the key, most importantly the "exportable" attribute which determines whether the key can later be exported back to the JS layer.
>> 
>> JWK seems attractive for this purpose since it is straightforward to define additional attributes to be carried with the key. The entire JWK JSON structure would then be wrapped using the key wrapping algorithm (for example AES Key Wrap).
>> 
>> WebCrypto supports public/private key pairs and symmetric keys. Hence JWK would need to be extended to support private and symmetric keys to be used for this purpose.
>> 
>> (2) Provision of keys to the HTML Encrypted Media Extensions "clear key" keysystem 
>> 
>> The Encrypted Media Extensions provide an API for a script to interact with a "Content Decryption Module" within the UA that provides key exchange and content decryption capabilities. It is expected that the well-known DRM vendors will provide "Content Decryption Modules" that are integrated into browsers and/or that platform APIs for such modules will be available for browsers to integrate with (e.g. in the case that the capability is present within the OS on a given platform.)
>> 
>> Additionally, the W3C group itself will define a simple "clearkey" Content Decryption Module in which the key is passed, in the clear, directly from the JS to the UA. This keysystem has application in certain specific security models (for example if the user is also the owner of the content) and for testing.
>> 
>> The keying material is passed to the CDM in the form of an opaque keysystem-specific byte array, which for clearkey must specify one or more (symmetric, likely AES) keys and associated Key Ids. Again, JWK seems an excellent simple candidate for this purpose, if it supported symmetric keys.
>> 
>> 
>> I understand that the JWK specification can be extended by registering the necessary additional attributes with IANA on a "Specification Required" basis. However, it was generally agreed in last week's W3C meetings that it would be better if this work was done in the IETF JOSE group.
>> 
>> Therefore, the upshot of this email is to ask if there is support in the IETF JOSE group for adding private and symmetric keys to JWK ?
>> 
>> I understand there is a draft for private keys already existing. I would be more than happy to propose a draft for symmetric keys if there is interest in progressing that here.
>> 
>> Finally, just to avoid any confusion, I should say that whilst the above approaches had general support in last week's W3C meeting, this is not a formal communication from the W3C (W3C groups tend not to send formal "liaisons").
>> 
>> Best regards,
>> 
>> Mark Watson
>> Netflix
>> 
>> [1] http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
>> [2] http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
>> [3] http://www.w3.org/2012/webcrypto/WebCryptoAPI/
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Sun, 11 Nov 2012 20:36:49 -0500

Hey Mark,

Do you mind if I incorporate these in the JOSE use cases document?
<http://tools.ietf.org/html/draft-barnes-jose-use-cases>

--Richard

On Nov 7, 2012, at 4:45 PM, Mark Watson <[email-masked]> wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Mark Watson <[email-masked]>
Date: Mon, 12 Nov 2012 02:53:35 +0000

> <http://tools.ietf.org/html/draft-barnes-jose-use-cases>

Please go ahead!

…Mark