Re: crypto-ISSUE-30 (where is the key ?): How does the application know where the key is stored ? [Web Cryptography API]

On 8/29/12 11:32 AM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote:

On Wed, Aug 29, 2012 at 8:45 AM, Seetharama Rao Durbha
<S.Durbha@cablelabs.com<mailto:S.Durbha@cablelabs.com>> wrote:
Providing my thoughts on this.

On 8/28/12 7:10 PM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote:

Just a quick note - I think the discussion related to key querying
(that is, previously authorized or pre-provisioned) and key discovery
(discovery of keys not explicitly granted) is too complex and the
needs not well understood enough to support adding this to the draft.


I've made note to highlight ISSUE-30, but I have concern adding this
API for FPWD.


I agree that key query needs to fleshed out a little further before it goes
into FPWD. I think having ISSUE-30 highlighted in the FPWD should appease
anyone looking for the functionality.


In order to better understand what you're proposing here:
1) Can you please provide a sample of what you imagine "KeyLocation"
containing.


In my mind, the coarse-grained classification of 'internal' vs 'external'
could be used. Essentially, it means whether the key is stored within
browser's own storage (including ones it has direct access to – like
KeyChain used by Chrome), or externally (primarily accessed through PKCS#11
providers).

[BTW, key stores other than browser's own – like KeyChain – could be a third
category, but I do not want to complicate things right away.]

Have you ever actually used OS X's Keychain or reviewed the API documentation?

It is an abstraction layer that represents a wide variety of storage types:
1) Physical storage on disk, unencrypted
2) Physical storage on disk, encrypted
3) Storage within a TPM
4) Storage within a smart card

In that respect, it is a functionally and fundamentally equivalent API
to PKCS#11 - the so called "external".

Tell me, would the browser know that it is using OSX's KeyChaiin API vs generic PKCS#11 provider/module? Unless you tell me otherwise, that is your distinction between external and KeyChain.
We cannot look into a PKCS#11 provider's implementation to see if they are storing/fetching keys on the local disk or on external tokens. That is not our concern. We can only inform the application / user about the nature of the provider used for fetching / storing key. Since we cannot standardize the provider names, thus the concept of 'external' - which are all PKCS#11 based for now.


The notion that there is somehow some distinction between these two
APIs is fundamentally flawed. All Keychain access is logically and
functionally "external" to the browser - but that is, of course, not
what you want - you want "external to the general purpose operating
environment", a very different notion.

Further, a user agent can implement its "own" storage (an already
problematic notion/distinction) in terms of using Keychain APIs,
either in a way that is "distinct" from the "other" stores (again,
problematic) or in ways that are identical and indiscernable to the
user agent. Thus, all key storage may be simultaneously "internal" and
"external"


2) Can you please provide a use case for how an application would use
"KeyLocation"


Given the classification above, the application can query for 'external'
keys (satisfying some other criteria that we will get to when we discuss
this topic in detail)

Since this is query only, let's postpone any further discussion until
we look at an ontology for querying.


3) Can you please provide an example of how "KeyLocation" may be
implemented by all conforming user agents, in a manner that is
agnostic to the method of key storage they use?


If the classification I mentioned above is used, then I guess the semantics
of internal vs external are simple and can be uniformly implemented across
browsers.

No, they're not, and they cannot be.

The simple boolean "internal" and "external" is so fraught with
implementation dependence that it is, for any purposes of a web
application, meaningless.