> 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 protected]> >> Subject: JSON Web Key support for private and symmetric keys >> Date: November 5, 2012 11:31:53 AM PST >> To: <[email protected]> >> >> 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/ >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
