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 2:20 PM, Seetharama Rao Durbha
<> wrote:
> On 8/29/12 2:43 PM, "Ryan Sleevi" <> wrote:
> On Wed, Aug 29, 2012 at 1:11 PM, Lu HongQian Karen <>
> 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.

This is only true for the subset of users whose security needs and use
case match yours.

I believe the vast majority of consumers of this API will not be
operating under the same security concerns or requirements that you
have proposed.

This goes back to the "High-Value Transaction" conversation had very
early on. There are certain transactions where paranoia must reign.
Not every transaction is that way.

Received on Wednesday, 29 August 2012 21:24:08 UTC