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

RE: Use case classification, and associated security models

From: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Date: Wed, 13 Jun 2012 14:57:59 +0000
To: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, Wan-Teh Chang <wtc@google.com>
CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-ID: <382AD43736BB12439240773F68E907738D41DD@DF-M14-21.exchange.corp.microsoft.com>
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.

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

Received on Wednesday, 13 June 2012 14:59:06 UTC

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