W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2013

Re: basic principle of key ownership

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 29 Apr 2013 10:45:59 -0700
Message-ID: <CACvaWvZhbXyzLEUWGwqQxrbLCE3XGSGi4+fgNnmVPfm2AWWciA@mail.gmail.com>
To: Mountie Lee <mountie@paygate.net>
Cc: Web Cryptography Working Group <public-webcrypto@w3.org>
On Sun, Apr 28, 2013 at 2:40 AM, Mountie Lee <mountie@paygate.net> wrote:
> Hi.
> I think we need agreement for principle of key ownership between working
> group members.
> key ownership is divided into two sides.
> - provisioner side : mostly like cloud, server or web application side.
> - user side : the user as human.
> when we review the issues with different view of key ownership,
> the result is totally different.
> I exampled followings.
> [sign]
> - in the view of provisioner side, signature will be generated silently.
> - in the view of user side, signature will be generated with user consent.
> [erasure]
> - in the view of provisioner side, the key can be erased silently like
> garbage collection.
> - in the view of user side, the key should not be erased without user
> consent.
> [key generation]
> - in the view of provisioner side, the key will be generated silently.
> - in the view of user side, the key will be generated with user consent.
> [pre-provisioned key]
> - in the view of provisioner side, the use case is acceptable.
> - in the view of user side, the use case is unacceptable. because user did
> not allow it.
> [same-origin policy]
> - in the view of provisioner side, it is strong security policy because the
> key is binded to some of provisioners.
> - in the view of user side, user is able to use "my key" on any sites with
> my decision
> ---------------
> as we see the above examples,
> the results are very different by the understanding of key ownership.
> non-US banking use cases (Korea, EU...)
> are based on "USER has key ownership"
> the key means certificate and it's binded private key.
> when the WG members agree this principle, the many conflicts can be easily
> solved.
> regards
> mountie.
> --
> Mountie Lee
> PayGate
> Tel : +82 2 2140 2700
> E-Mail : mountie@paygate.net
> =======================================
> PayGate Inc.
> for Korea, Japan, China, and the World

As I described in your other message on this topic ("Who owns the
key"), this model fails to take into account the real-world nuances
that exist when talking about ownership.

You've presented two possible owners:
- provisioner
- user

However, in the real world, it's often a 3 or 4 corner model, with the
application being a distinct entity than the provisioner, as well as
the possibility of organizations that certify such applications.

This can be easily seen in the Global Platform model of applications that exist.

Likewise, as I described on that other thread, the model of ownership
currently described by the API keeps the entire security boundary
exactly where it has remained for all other web features - at the
scope of the origin.

That is, the origin owns the key and can do anything with the key. If
the origin is compromised, so too is the key. There are things you can
do to reduce or eliminate the risk of the origin being compromised -
ranging from CSP to using 'alternative' origins (such as those found
in extensions/sysapps), but the model remains the same - at the origin

As noted since the beginning of this WG, exposing pre-provisioned keys
(whether via smart card, device, or other) under this model opens up a
host of new security concerns that will require significant care and
thought in addressing. Which is why you do not find support for them
in the API.

As reflected in the charter, this WG has decided to prioritize its
efforts based on those keys that fit within the existing origin
security model.
Received on Monday, 29 April 2013 17:46:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:16 UTC