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 2:43 PM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote:

On Wed, Aug 29, 2012 at 1:11 PM, Lu HongQian Karen <karen.lu@gemalto.com<mailto:karen.lu@gemalto.com>> wrote:
The application's trust model does not totally depend on what UA tells it where the key comes from. This is a reference and a first level of checking. The application or the back-end server can verify operations done using the key and, hence, if the right key was used. What is the harm of telling the application since the UA knows the information?

The (significant) harm is that it requires us to figure out an
taxonomy of key storage types, while still having the spec remain
neutral about the details about how or what is implemented. The
problem with such taxonomies, especially spec'd before any
implementations exist, is that by framing the language in particular
terms, you directly and indirectly influence what is seen as
implementable and how things are implemented, and inevitably, the
taxonomy fails when things are "like-but-not-alike", much like
Keychain is "Local but not local" or a remote cloud storage is
"Browser storage, but external"

Even simple, mechnical definitions such as "software, hardware,
removal" are, in fact, subtle and complicated, and fail to classify
even the existing types of key storage provided by common APIs today.


Your quoted discussions mentioned that an application could not trust what UA said in a certain aspect. Is this the trust model of this API? Isn't the UA the one who implements the API? How would an application know to trust or not anything from the API?

Yes, the trust model of this API, as with every other client-side API,
as with every other JavaScript API, as with every other crypto API, is
that you should not and cannot trust the API. The API can lie or be
subverted, and there is no way, as a server, to know this.

One of the core, most foundational, unconditional premises for web
security, is never, EVER, trust the client.

The ONLY thing you should trust are things you know cannot be
subverted. This would include trusting a key provisioned on a smart
card, if you KNEW that the smart card could not be subverted, no
matter how hostile the environment.

If we have the best interests of the developers in mind, then may be we can limit our API to operations possible on a smart card (and strictly using pre-provisioned keys). No key derivation also (as that exposes the key to browser). Anything else will help in the development of applications using false assumptions.