- From: Ryan Sleevi <sleevi@google.com>
- Date: Mon, 29 Apr 2013 10:45:59 -0700
- 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 > CTO, CISSP > Tel : +82 2 2140 2700 > E-Mail : mountie@paygate.net > > ======================================= > PayGate Inc. > THE STANDARD FOR ONLINE PAYMENT > 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 level. 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