RE: Use case classification, and associated security models

Exactly, this is what I had in mind (as I also mentioned on the other email to Ryan).

-----Original Message-----
From: David Dahl [mailto:ddahl@mozilla.com] 
Sent: Wednesday, June 13, 2012 10:40 AM
To: Vijay Bharadwaj
Cc: public-webcrypto@w3.org; Wan-Teh Chang
Subject: Re: Use case classification, and associated security models

----- Original Message -----
> From: "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com>
> To: "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com>, "Wan-Teh Chang" 
> <wtc@google.com>
> Cc: public-webcrypto@w3.org
> Sent: Wednesday, June 13, 2012 9:57:59 AM
> Subject: RE: Use case classification, and associated security models
> 
> One more clarification - I'm also implicitly making the assumption 
> that keys used in scenarios #1 and #2 are not eligible for naming (at 
> least as exposed outside the app), and cannot be queried for by a 
> server. Names are only for long-term persisted keys with trusted 
> provenance as in scenario #3. Specifically, keys that are provisioned 
> out-of-band or created as part of something like a certificate 
> enrollment operation signed by an out-of-band provisioned key.

I think in scenarios 1 & 2 the browser will name the key. This will be needed so that sites can utilize multiple keys for multiple apps or in exchanging data with multiple parties. I can see the generateKeys function returning a key ID object (that has a URI + sequence or UUID, etc. as ID property) that can be stored on the server or in localStorage for later retrieval. I agree these keys may not be queried for as the application has a chance to store the key ID object.

David

Received on Thursday, 14 June 2012 00:48:54 UTC