- From: Mountie Lee <mountie.lee@mw2.or.kr>
- Date: Fri, 24 Aug 2012 16:50:13 +0900
- To: Ryan Sleevi <sleevi@google.com>
- Cc: Wan-Teh Chang <wtc@google.com>, Seetharama Rao Durbha <S.Durbha@cablelabs.com>, David Dahl <ddahl@mozilla.com>, Web Cryptography Working Group <public-webcrypto@w3.org>
- Message-ID: <CAE-+aYKQvYW2VYZKvh8t1saPOj9PixkhNQWu14rQ7WQREx7ZPA@mail.gmail.com>
Hi. let me comment for this issue more. the asymmetric keys has two types in web crypto api discussions. simple public-private key pair and certificate-private key pair. with public-private key pair, I have no question for same-origin policy and other session dependent operations. but with certificate-private key pair, certificate is the result of very old , deep and wide discussions. certificate has it's own trust mechanism and it is one of web infrastructures. following is the usecase in Korea that describes why multi-origin access is necessary in webcrypto api as we know, over 25 millions of certificates are issued from CAs in Korea. the certificates were issued by verifying user identity by face-to-face meeting in multiple locations nationwide. the CAs were established , audited by legal regulation we don't want to draw existing certificates to trash because of multi-origin access issue. CA will initiate key generation and issue certificate. now CA is became 'origin-A' and the key pair is became 'key-A' origin-B want signed document from user with the signature generated by 'key-A' because the 'key-A' is issued from legally trusted CA. if webcrypto api keep the same-origin policy, the origin-B will try to generate and use it in their domain. not nationwide. the origin-B will try to use alternatives (script-src, web intents, CORS and so on) but origin-B can not use alternatives because of following reasons. script-src is not affordable because maybe origin-B will prepare a page loading script from origin-A maybe the crypto operation will work fine until origin-A is live and did not make any mistake for their script. using script src means origin-B is always dependent on origin-A. it is high business risk, can not guarantee the reliability of service of origin-B. and also connectivity issues are exist. if user agent has lost/restriction connectivity to origin-A like web tv or offline web applications, dependency of origin-A will cause problem to service 'B'. Web Intents is not affordable because it is user-initiated feature. that means origin-B can not initiated the CryptoOperation without user's accurate actions. it's aim is enriching the user experiences. not expand infrastructure I'm not sure web intents are supported in other user agents except chrome. iframe or postMessage is not affordable. because with those technologies, we can not make continuous web application. with those technologies, calling ONCE for cross-site resource. exchanging multiple request/response for cross-site resource is restricted. CORS is great solution. but I think we have to consider followings. CORS is applicable both HTTP and HTTPS. HTTP is risky CORS has dependency to server side. if server does not support CORS, user agents with CORS feature has no meaning. we can not make sure all service operators has enough knowledge installing CORS supported apache server, controlling server side. my basic idea is removing dependencies as much as. WebCryptoAPI itself is good enough. but if we think more balance for multi-origin access in WebCrypto API, I suggest followings. allowing multi-origin access as following conditions - associate with valid certificate (client and server both or server only. depending on user agent's decision) - CORS enabled server environment. I hope we success to make consensus for multi-origin access policy. regards mountie. On Thu, Aug 23, 2012 at 10:46 AM, Ryan Sleevi <sleevi@google.com> wrote: > On Wed, Aug 22, 2012 at 6:28 PM, Wan-Teh Chang <wtc@google.com> wrote: > > It would be nice for implementations to be able to support two types > > of key access: > > - origin-bound keys > > - shared keys that are associated with certificates > > > > The Key object should be specified to have an attribute related to > > which origins may use the key. We can start with supporting > > origin-bound keys only. > > > > Also, after a signing key has been used, it seems dangerous to broaden > > the origins. I am worried that an old signature generated when only > > one origin was allowed may become valid for other origins > > retroactively. So this key attribute for access control probably > > should be immutable for signing keys at least. > > > > Wan-Teh > > Mountie, Wan-Teh, or Seetharama, > > Could one of you please write-up a concrete Use Case for multiple > origin key access? I want to make sure we have a place where we can > capture: > 1) Why is it useful/valuable > 2) What are the security and privacy risks > 3) Why other alternatives are not suitable > 3a) script-src , which inherits the SOP of the including domain > 3b) Web Intents > 3c) inter-origin communication mechanisms (postMessage, iframe, CORS, > etc) > > I'm deeply concerned about #2 here, so I want to make sure we can > actually have something concrete to discuss. > > I also don't believe we should attempt to reach consensus on this > issue prior to FPWD. As referenced in previous documents, the state of > the art and the active encouragement of the web community is not to > violate the SOP. In order to help reviewers understand why the > violation is useful or important, I think a strong use case will need > to be presented. > ======================================= PayGate Inc. THE STANDARD FOR ONLINE PAYMENT for Korea, Japan, China, and the World
Received on Friday, 24 August 2012 07:51:25 UTC