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

Received on Wednesday, 13 June 2012 14:24:33 UTC