RE: Use case classification, and associated security models

True. I was thinking about this from the perspective of what the browser needs to do to help with access control of the key. My thinking was that in #2 there was no persisted object to control access to. But your formulation works as well.

-----Original Message-----
From: Wan-Teh Chang [mailto:wtc@google.com] 
Sent: Wednesday, June 13, 2012 5:55 PM
To: Vijay Bharadwaj
Cc: public-webcrypto@w3.org
Subject: Re: Use case classification, and associated security models

Hi Vijay,

Thank you for answering my question.  I'm sorry my question wasn't clear.  I didn't mean to make you write about the difference between GenerateKey and ImportKey.  My question was really about what you called "key provenance".

On Wed, Jun 13, 2012 at 7:23 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com> wrote:
>
> 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.

The distinction you made here does not seem important. In a Diffie-Hellman key exchange, the app derives the key locally, taking the other party's public key as input.  It is very similar to scenario #1.

It seems that the important property is whether a key is to be used only by that app (or rather, web origin), or is to be shared by multiple apps (web origins), and whether a key is temporary or persistent.  Whether the key is produced by a key generation or key exchange procedure seems less important.

Wan-Teh

Received on Thursday, 14 June 2012 01:05:47 UTC