- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Thu, 09 May 2013 23:12:18 +0200
- To: Mountie Lee <mountie@paygate.net>
- CC: Seetharama Rao Durbha <S.Durbha@cablelabs.com>, Lu HongQian Karen <karen.lu@gemalto.com>, Arun Ranganathan <arun@mozilla.com>, "public-webcrypto@w3.org Working Group" <public-webcrypto@w3.org>
- Message-ID: <518C1132.1080503@gmail.com>
I don't think so, but, again, what is the point here? If you are compromised, nothing can save you. Regards, Le 08/05/2013 04:17, Mountie Lee a écrit : > for ensuring script integrity, > we can use the suggestions of webappsec WG's CSP. > > > > On Wed, May 8, 2013 at 2:18 AM, Seetharama Rao Durbha > <S.Durbha@cablelabs.com <mailto:S.Durbha@cablelabs.com>> wrote: > > User cannot tell if the scripts are compromised, so will not know > if he is authorizing the key usage for signatures to the correct > origin's scripts. > > On 5/7/13 11:15 AM, "Aymeric Vitte" <vitteaymeric@gmail.com > <mailto:vitteaymeric@gmail.com>> wrote: > > One way I would see to solve the key ownership issue or PIN > code discussions, would be to have a user password mechanism > with indexedDB, which does not exist. > > Regards, > > Aymeric > > Le 07/05/2013 18:38, Mountie Lee a écrit : >> Hi. >> >> if the signature is generated by the operation of origin and >> sent to 3rd party as user's signature, >> how the 3rd party can trust signature? >> >> non-repudiation is legal term in Korea and EU. >> >> even with trusted origin, >> if the certificate key pair is controlled NOT by user BUT by >> origin, the generated signature can not be trusted. >> >> accessing to private key of certificate key pair need user >> consent. not allowing silent operation for certificate key pair. >> >> for existing TLS client x509 certificate, your comment is >> right and not convenient to control. >> that is the reason charter described TLS login/logout or >> other features. >> >> regards >> mountie. >> >> >> >> >> >> On Wed, May 8, 2013 at 1:10 AM, Seetharama Rao Durbha >> <S.Durbha@cablelabs.com <mailto:S.Durbha@cablelabs.com>> wrote: >> >> I am not sure I follow what is meant by user owns the >> cert Vs. origin owns the cert. For all practical >> purposes, the origin uses a secure protocol to associate >> a cert to a user. Cert could have been obtained by the >> user from a 3rd party or issued by the origin. But for >> non-repudiation purposes, it does not matter. >> >> The problem for non-repudiation is whether someone else >> could have generated the signature. With no secure SOP, a >> malicious script can easily generate the signature and >> submit to the origin. >> >> In case of TLS, there are no signatures involved, and the >> keys are not exposed to scripts. The user can demonstrate >> the ownership of a certificate to anyone who cares – >> whether malicious content or genuine content. So, TLS >> usage is totally different. >> >> >> On 5/7/13 9:44 AM, "Mountie Lee" <mountie@paygate.net >> <mailto:mountie@paygate.net>> wrote: >> >> existing TLS client X509 certificate can be used on >> any sites for establishing TLS connection. >> >> if keys are totally owned by origin, the origin has >> full control for the keys of UA with silent operation. >> if keys are owned by user, the origin has limited >> control for the keys with user consent (like TLS >> client x509 certificate). >> >> before going to certificate discussion, >> we have to conclude how to handle key ownership issue >> and solve the conflict between existing TLS client >> x509 certificate and webcrypto's certificate. >> >> the definition of certificate in >> wikipedia(http://en.wikipedia.org/wiki/Public_key_certificate) >> describe as following >> "In cryptography >> <http://en.wikipedia.org/wiki/Cryptography>, a >> *public key certificate* (also known as a *digital >> certificate* or *identity certificate*) is an >> electronic document that uses a digital signature >> <http://en.wikipedia.org/wiki/Digital_signature> to >> bind a public key >> <http://en.wikipedia.org/wiki/Public_key> with an >> identity — information such as the name of a person >> or an organization, their address, and so forth. The >> certificate can be used to verify that a public key >> belongs to an individual." >> >> the certificate is issued to identify the entities >> (individuals or organizations) >> means >> >> certificate is tightly binded into key ownership. >> >> if the keys are controlled by origins (provisioners, >> servers or the cloud), it can not be used for >> non-repudiation of individual. >> technically the cross-origin issued can be addressed >> with suggested solutions (CORS, postMessage...). >> but it can not be the answer for non-repudiation >> requirement. >> >> user owns the certificate key pair and has control >> --> generated digital signature --> non-repudiable >> >> regards >> mountie. >> >> >> On Wed, May 8, 2013 at 12:14 AM, Seetharama Rao >> Durbha <S.Durbha@cablelabs.com >> <mailto:S.Durbha@cablelabs.com>> wrote: >> >> With the ownership of the key based on SOP that >> is not cognizant of tampering (as of now), I am >> afraid that any discussion of signatures will be >> futile, they cannot be used for non-repudiation, >> at the end of the day. >> >> http://lists.w3.org/Archives/Public/public-webcrypto/2013Apr/0247.html >> >> >> On 5/6/13 10:38 AM, "Lu HongQian Karen" >> <karen.lu@gemalto.com >> <mailto:karen.lu@gemalto.com>> wrote: >> >> Hi Arun, >> >> Here are the two use cases that I have talked >> about at the recent F2F meeting. >> >> Cross-origin use cases: >> >> 1.Asymmetric key use case: A healthcare >> association (origin 1) issued Dr. Smith an >> X.509 certificate and the corresponding >> private key. Dr. Smith accesses an >> e-prescription service (origin 2) and uses >> her private key to sign e-prescriptions. >> >> 2.Secret key use case: Danny signed up at a >> cloud storage (origin 1) that created him a >> secret access key and persisted it through >> Danny’s UA. Danny stores his 3D model data in >> the cloud storage. He then uses an online 3D >> printing service (origin 2) to print his >> model. To access Danny’s model in Origin 1, >> Origin 2 needs to use Danny’s secret key. >> Danny tells Origin 2 certain attribute(s) of >> his key. The Origin 2 finds the key object >> through the UA and uses the key to sign API >> requests for getting the model from cloud >> storage. >> >> Although these two use cases are out of the >> current WG scope. It’ll be good to collect >> them for future work. >> >> Regards, >> >> Karen >> >> >> >> >> -- >> 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 >> >> >> >> > > -- > jCore > Email :avitte@jcore.fr <mailto: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 <http://www.jcore.fr> > Webble :www.webble.it <http://www.webble.it> > Extract Widget Mobile :www.extractwidget.com <http://www.extractwidget.com> > BlimpMe! :www.blimpme.com <http://www.blimpme.com> > > > > > -- > 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
Received on Thursday, 9 May 2013 21:09:53 UTC