Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <26E00E85-A8B9-4E5C-87AC-F2087D7E7C58@netflix.com>
Date: Sun, 11 Nov 2012 20:36:49 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <FD28E520-006A-4DFB-9F3B-C49B824B94AD@bbn.com>
References: <2D8B50D1-6135-4D3F-B288-8B690F5B9ACA@netflix.com>
 <26E00E85-A8B9-4E5C-87AC-F2087D7E7C58@netflix.com>
To: Mark Watson <watsonm@netflix.com>
Cc: "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] RESEND: JSON Web Key support for private and symmetric keys
Precedence: list

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 <watsonm@netflix.com> wrote:

>> All, I was hoping to get this to you before your meeting, but get =
repeated delivery failures. One more try ...
>>=20
>> Begin forwarded message:
>>=20
>>> From: Mark Watson <watsonm@netflix.com>
>>> Subject: JSON Web Key support for private and symmetric keys
>>> Date: November 5, 2012 11:31:53 AM PST
>>> To: <jose@ietf.org>
>>>=20
>>> All,
>>>=20
>>> 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).
>>>=20
>>> 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:
>>>=20
>>> (1) Key wrap/unwrap in the WebCrypto API
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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).
>>>=20
>>> 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.
>>>=20
>>> (2) Provision of keys to the HTML Encrypted Media Extensions "clear =
key" keysystem=20
>>>=20
>>> 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.)
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>>=20
>>> 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.
>>>=20
>>> 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 ?
>>>=20
>>> 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.
>>>=20
>>> 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").
>>>=20
>>> Best regards,
>>>=20
>>> Mark Watson
>>> Netflix
>>>=20
>>> [1] =
http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-me=
dia.html
>>> [2] =
http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.ht=
ml
>>> [3] http://www.w3.org/2012/webcrypto/WebCryptoAPI/
>>=20
>=20
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose