W3C home > Mailing lists > Public > public-identity@w3.org > January 2012

Re: Netflix use case doc posted

From: Mitch Zollinger <mzollinger@netflix.com>
Date: Fri, 27 Jan 2012 15:51:32 -0800
Message-ID: <4F233884.20404@netflix.com>
To: "Richard L. Barnes" <rbarnes@bbn.com>
CC: <public-identity@w3.org>
On 1/26/2012 2:51 PM, Richard L. Barnes wrote:
> Hey Mitch,
>
> Thanks for writing this up.  It should be very helpful, especially in clarifying key management requirements.  In general, it seems like a good design goal would be to allow key material to live entirely within the crypto module (inaccessible to Javascript) for the great majority of applications.
>
> The one thing in your document that seemed odd to me was the part about key wrapping:
> "
> var Ks = webcrypto.getRandom(16);
> var wrappedKs = webcrypto.encrypt(Ks, Kab, aes-128-cbc);
> "
>
> It seems like you could just as well have the crypto module generate an internal key and export the wrapped version, something like:
> "
> var Ks = webcrypto.generateSymmetricKey(16);
> var wrappedKs = webcrypto.exportWrappedKey(Ks, Kab, aes-128-cbc);
> "

Good catch. Yes, I agree with you completely.

In keeping with my simplification that there are no key handles, I'd 
like to propose a small tweak to your code above:

   webcrypto.generateSymmetricKey(/*key size in bytes*/16, /*key name*/"Ks");
   var wrappedKs = webcrypto.exportWrappedKey("Ks", Kab, aes-128-cbc);

I made a note in the doc that KeyHandle is probably a more flexible 
mechanism, but the above is more consistent with the rest of the doc. 
(I've updated the doc with your suggestion.)

> ... where in this case, Ks stores a handle to the internal key, just like "Kab".
>
> Likewise, key derivation (transformSS) will require some ability to transform values within the key store.  It seems like the basic choice here is how to constrain the space of transforms:
> 1. Single, fixed transform
> 2. Finite list of fixed transforms
> 3. Pass in a function to be applied
> Your transformSS example seems to assume (1) (based on RFC2631), but it might also be useful to be able to add in other information (nonces) or apply things like pseudo-random functions.

Agreed. My example was for illustrative purposes & the obvious use case 
we have for D-H.

>
> (As a benchmark, I'm trying to imagine whether you could use this API to do standard RSA-based TLS key establishment, in which case you need to do the following computation within the crypto boundary:
> 1. Unwrap a pre_master_secret
> 2. Compute master_secret = PRF(pre_master_secret, "master secret", nonces)
> So you would need unwrapping and the application of the PRF to happen within the boundary.)

Out of curiosity, why would you want to do a TLS key establishment in 
Javascript?

>
> Hope this helps,

Very helpful, indeed. Thanks for the input.

Mitch

> --Richard
>
>
>
>
> On Jan 6, 2012, at 7:00 PM, Mitch Zollinger wrote:
>
>> Hi all,
>>
>> Happy New Year!
>>
>> I posted this before the holidays:
>> http://www.w3.org/wiki/NetflixWebCryptoUseCase
>>
>> Input appreciated.
>>
>> Mitch
>>
>>
>
Received on Friday, 27 January 2012 23:52:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 January 2012 23:52:02 GMT