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

On Wed, Aug 29, 2012 at 8:45 AM, Seetharama Rao Durbha
<S.Durbha@cablelabs.com> wrote:
> Providing my thoughts on this.
>
> On 8/28/12 7:10 PM, "Ryan Sleevi" <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".

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.

Received on Wednesday, 29 August 2012 17:32:28 UTC