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 10:51 AM, Seetharama Rao Durbha
<S.Durbha@cablelabs.com> wrote:
>
>
> On 8/29/12 11:32 AM, "Ryan Sleevi" <sleevi@google.com> wrote:
>
> 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".
>
>
> 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.

CryptoAPI is not PKCS#11 based.
CNG is not PKCS#11 based.
With the exception of Boot 2 Gecko, I'm not aware of a single mobile
implementation that is PKCS#11 based.

The concept of "external" == "PKCS#11" is implementation dependent and
thus, for applications, unworkable.

>
>
> 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 18:02:53 UTC