Re: Use case classification, and associated security models

On Wed, Jun 13, 2012 at 7:57 AM, Vijay Bharadwaj <
Vijay.Bharadwaj@microsoft.com> wrote:

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

Could you explain a bit more about this?

I would think that some form of symbolic naming will be an important part
of making a usable API. I'm not sure the use case for why they wouldn't be
needed?

If a web application wishes to use multiple RSA keys, which it provisioned
via scenario #1 during some prior visit, what is the intended way for it to
disambiguate the keys.


>
> -----Original Message-----
> From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com]
> Sent: Wednesday, June 13, 2012 7:23 AM
> To: Wan-Teh Chang
> Cc: public-webcrypto@w3.org
> Subject: RE: Use case classification, and associated security models
>
> The only API-level difference between #1 and #2 in my mind was that #1
> talked about a GenerateKey operation (and sort of implied an ExportKey
> operation) whereas #2 talked about ImportKey. So from an API perspective,
> the difference is that #1 requires a strong source of randomness and an
> ability to generate keys (including things like prime number generation and
> so on) whereas #2 doesn't.
>
> >From the perspective of key provenance, in #1 the key is generated within
> the app so the browser knows who generated the key and can tag it with
> appropriate metadata. In #2 the browser doesn't necessarily know where the
> key came from - it is embedded in some protocol that is run by the app - so
> the browser cannot validate provenance. However, I don't think this needs
> to be reflected in the API separately - the fact that an app does an
> ImportKey operation should indicate that the app is responsible for
> ensuring the provenance of the key.
>
> -----Original Message-----
> From: Wan-Teh Chang [mailto:wtc@google.com]
> Sent: Tuesday, June 12, 2012 4:54 PM
> To: Vijay Bharadwaj
> Cc: public-webcrypto@w3.org
> Subject: Re: Use case classification, and associated security models
>
> Hi Vijay,
>
> Thank you for writing this up.
>
> I agree that the design of the Web Cryoto API can be divided into two
> parts:
> - key management
> - the actual crypto operations that take a key object
>
> As for the three scenarios of key management you described, the difference
> between scenario 1 (Ephemeral or local-only keys) and scenario 2 (Ephemeral
> keys obtained through key agreement) does not seem important for the API
> design. How do you think the API should reflect the different security
> models between scenario 1 and scenario 2?
>
> To me, the important distinction is between scenarios 1 & 2 and scenario
> 3. In scenarios 1 & 2, the browser knows which website generates or
> imports/derives the key.  That knowledge is recorded persistently and can
> be used to determine which website is authorized to open or use a key in
> the future if the key is persistent.
>
> Wan-Teh
>
>
>
>
>