W3C home > Mailing lists > Public > public-webcrypto@w3.org > June 2012

Re: Use case classification, and associated security models

From: David Dahl <ddahl@mozilla.com>
Date: Wed, 13 Jun 2012 10:39:30 -0700 (PDT)
To: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Cc: public-webcrypto@w3.org, Wan-Teh Chang <wtc@google.com>
Message-ID: <1126554336.7017601.1339609170034.JavaMail.root@mozilla.com>
----- 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.

Received on Wednesday, 13 June 2012 17:40:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:10 UTC