Re: Netflix use case doc posted

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”);
"
... 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.  

(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.)

Hope this helps,
--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 Thursday, 26 January 2012 22:51:31 UTC