Re: PROPOSAL: Close ISSUE-26 - Should key generation be allowed to specify multi-origin shared access

there are many discuss threads for multi-origin issues.
and I feel the solution was narrowed to certificate association.

but the certificate related issues were postponed because it was not in
primary features.

my main concern is that
closing this issue will cause final decision of dropping multi-origin
allowness.

I will still research and review the alternatives like CORS or script-src.
but I feel still we need to handle multi-origin and certificate both.

regards
mountie.





On Fri, Feb 1, 2013 at 10:24 AM, Ryan Sleevi <sleevi@google.com> wrote:

> On Thu, Jan 31, 2013 at 5:19 PM, Mountie Lee <mountie@paygate.net> wrote:
> > from the previous discussions
> >
> > I remember we have two proposals for this issue.
>
> There were not proposals. There were use cases, but no proposals on
> how to satisfy those use cases.
>
> >
> > one is allowing multi-origin shared acces for certificate associated
> case.
> > second is allowing multi-origin shared access by user consent
> >
> > the reason why this issue is important is
> >
> > in the online banking usecases.
> > users generate keypair at CA website and get certificate.
> > and the certificate-private key pair should be used at other bank sites
> for
> > signing document or verifying signature.
> >
> > as compared to TLS certificate usecases,
> > it is also common sense.
> > generating and getting certificate from CA site
> > and using it at different site
>
> And in that thread, solutions were explored on how that use case can be
> met.
>
> That said, we're talking more generally about credential enrollment,
> as you just described, which is clearly placed in our secondary use
> cases.
>
> I think that, absent any concrete proposals, and based on the
> timelines set out, this should not be seen as an ISSUE for the current
> spec. The WG has (by charter) agreed to look at this, but at a later
> point (the non-normative "roadmap" document).
>
> I'm proposing that, based on the lack of concrete proposals, and based
> on the timeline set forward, that we should consider this "not
> implemented due to time constraints".
>
> >
> >
> > On Fri, Feb 1, 2013 at 4:18 AM, Ryan Sleevi <sleevi@google.com> wrote:
> >>
> >> http://www.w3.org/2012/webcrypto/track/issues/26
> >>
> >> I would like to propose that we CLOSE Issue-26.
> >>
> >> There have been no proposals put forward on how to securely address
> >> multi-origin shared access. Further, such provisioning opens up a host
> >> of security concerns that the use cases used to justify such access
> >> are not compatible with.
> >>
> >> In the current specification, multi-origin applications may make use
> >> of secure messaging exchanges, such as postMessage, to transition
> >> across security domains, without requiring the granting of a single
> >> origin full access to either plaintext or to keying material.
> >>
> >> As such, absent both concrete use cases and proposals, I propose that
> >> this issue be closed.
> >>
> >
> >
> >
> > --
> > 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
> >
>



-- 
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