Re: crypto-ISSUE-26 (multi-origin access): Should key generation be allowed to specify multi-origin shared access [Web Cryptography API]

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