RE: Use case classification, and associated security models

Sorry, my original statement was not worded very well.

The idea I had in mind was that the scope of the name in scenarios #1 and #2 need not (should not?) exceed the scope of the key. In #1 the key is only meant to be used by the one app, and therefore it's okay if it cannot be referred to outside that app. Therefore in general other servers cannot probe for it. In #2 there is nothing to name. The key is not persisted - the app is just creating a key object by importing a blob received through some other means, and once it's done using it the key object can go away.

In other words I'm trying to limit consideration of cross-application long-lived keys (and hence the key querying issues) to scenario #3.

Does that make more sense?

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Wednesday, June 13, 2012 10:50 AM
To: Vijay Bharadwaj
Cc: Wan-Teh Chang; public-webcrypto@w3.org
Subject: Re: Use case classification, and associated security models

On Wed, Jun 13, 2012 at 7:57 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com<mailto: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<mailto:Vijay.Bharadwaj@microsoft.com>]
Sent: Wednesday, June 13, 2012 7:23 AM
To: Wan-Teh Chang
Cc: public-webcrypto@w3.org<mailto: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<mailto:wtc@google.com>]
Sent: Tuesday, June 12, 2012 4:54 PM
To: Vijay Bharadwaj
Cc: public-webcrypto@w3.org<mailto: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