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

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<mailto:sleevi@google.com>> wrote:
On Thu, Jan 31, 2013 at 5:19 PM, Mountie Lee <mountie@paygate.net<mailto: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<mailto: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<mailto: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<mailto:mountie@paygate.net>

=======================================

PayGate Inc.

THE STANDARD FOR ONLINE PAYMENT

for Korea, Japan, China, and the World