Re: [W3C WebCrypto API WG] Key discovery

Mountie,

Wy not use window.postMesage if cross-origin communication is required[1]?

This ensures that the domain that has access to the key storage has to explicitly allow the other domain to get access to it, using an established mechanism implemented in todays browsers.

Kind regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 425 41 02
Office fax: +32 3 821 01 71
nick.van.den.bleeken@inventivegroup.com<mailto:nick.van.den.bleeken@inventivegroup.com>
www.inventivedesigners.com


1: http://www.w3.org/TR/webmessaging/

On 11 Apr 2013, at 03:16, Mountie Lee <mountie@paygate.net<mailto:mountie@paygate.net>> wrote:

Key Discovery and same-origin policy is also in my question.

traditional TLS Client Certificate Storage can be initiated by any servers without considering origin related issues even the cert is issued from different origin.

but the webcrypto keystorage which is not yet contain certificate is binded to one origin.

the webcrypto api is trying to control TLS session with it's API in secondary feature.

how to solve these conflict?

I have thought following existing solutions with my comment.

[script-src]
If user access to originA loading script from originB that has binded keystorage.
can we control keystorage with the example "<script src=http://originB.domain.com/controlCertificate.js<http://originb.domain.com/controlCertificate.js> ...></script>"?
I'm not clear for this.

[CORS]
CORS is used to access resources in originB from client JS which initiated originA.
keystorage is in client local not in remote server.
but I think there is a possible considerations.

[full exception for certificate case]
add exception for certificate case which is valid and has trust anchor up to UA's trusted root CA list.
this also can be solution.

[user consent]
using user consent is not good solution.
maybe users will always click "yes" that was already proven in Korea.

regards
mountie.





On Thu, Apr 11, 2013 at 7:47 AM, Samuel Erdtman <samuel@erdtman.se<mailto:samuel@erdtman.se>> wrote:
Hi,

Relatively early in the webcrypt work I submitted a set of use-cases (to the public list) that where similar to what you sugests but with a clearer focus on certificates and there keys. You can find it here http://lists.w3.org/Archives/Public/public-webcrypto-comments/2012Jul/0000.html.

I have requirements similar to yours but since I submitted my use-cases I have learned a lot and changes my position a bit. I still have these requirements, but I think that it should be coupled to certificates not key attributes, and maybe not in webcrypto.

If I understand the draft that you sent, this discovery mechanism with issuer would not be bound to origin. I think this is wrong since by going outside the SOP we will open pandora's box of security and privacy issues.

One of the things that we would have to consider is that if I can query for the issuer of eId´s form every site then it would be very easy to track a user, and the issuer of the eId cannot prevent it. In my initial use-case the webpage would not get the key reference but just the signature if the user accepted to sign and something generic none compromising if the user denied the signature.

In a later mail I suggested to bind certificate and keys to a domain with an attribute specifying the domain (posible with wildcard), This would put the issuer in control of the usare of the certificate and keys.

After this I have come  more and more to the conclusion that we really should leave smart cards out of webcrypto, for the time being at least. There exists good but propertarian solution for handling smart cards and I thing that to handle smart-cards we would have to have a much wider scoop. I think that we should fokus on solution where we do not need smart cards for example in the nordic countries we are moving away from smart cards for eId´s and moving towards server-side signares and short lived certificates (one session only) that is issued when the user can provide some other form of strong authentication e.g. OTP. Then we have the mobile situation where smart cards do not suite very well i.e. we need other solutions. Therefor I think that we should let webcrypto solve problems more relevant to the future then smart cards.

Best Regards
Samuel Erdtman
Technology Nexus Product Manager





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





________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer