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

Hi.
if Key A generated by the script loaded from origin-A,
will be the Key-A accessable from origin-B with CORS headers?

if CORS controls are deployed to generated Key resource,
we found improvement.


On Thu, Feb 7, 2013 at 11:25 PM, GALINDO Virginie <
Virginie.GALINDO@gemalto.com> wrote:

> Hi Mountie, Ryand, and all,****
>
> ** **
>
> About the certificate management. ****
>
> This is a discussion I wanted to have during our last call : how to
> address the secondary features. It seems to me that if this topic if of
> importance for you, you should start considering creating a draft
> specification to address it. ****
>
> As I have mentioned several time, the WG welcomes contributions, even on
> secondary features. If there is a contribution, you will get some time to
> present it, and discuss it, with a low priority in the agenda compared to
> primary features, but at least, it will allow the group to understand why
> it is important and how it is feasible to manage certificates. ****
>
> ** **
>
> About the multiple-origin. ****
>
> I would suggest that if there are some interested parties, they come
> together with a proposal to the editors, as I recommend for the ISSUE-19.
> ****
>
> ** **
>
> Regards,****
>
> Virginie****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* mountie@paygate.net [mailto:mountie@paygate.net] *On Behalf Of *Mountie
> Lee
> *Sent:* samedi 2 février 2013 05:34
> *To:* Ryan Sleevi
> *Cc:* public-webcrypto@w3.org
> *Subject:* 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****
>
> ** **
>
>


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