Re: [W3C WebCrypto API WG] Key discovery

Le 11/04/2013 03:16, Mountie Lee a écrit :
> 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.

Yes and no, if originA is loading tls resources from "originB" (that I 
would better call destinationB in that case) and the certificate can not 
be checked, this will just silently fail. But you can call directly tls 
"originB", add an exception and then back to originA request tls 
"originB" and this will work.

I am wondering about this too, the current mechanism does allow things 
that are not possible with the API following SOP, but for now I still 
don't think it's a good idea at all to try to mix the current storage 
mechanism with the API's one.

>
> 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 ...></script>"?
> I'm not clear for this.

No, if you allow the script of "originB" to load into originA, the 
script will just be able to access the storage of originA, not B

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

Same, the origin is the origin of the page (then A) whether for example 
xhr is allowed to load resources from "originB", this will still be 
managed in the context of originA, if you want to access originB storage 
the page must be loaded from originB (normal page, iframe, etc), maybe 
take a look at my John and Sandy use case as an example.

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

Back to my initial comment above

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

-- 
jCore
Email :  avitte@jcore.fr
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com