- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Tue, 07 May 2013 19:32:54 +0200
- To: Seetharama Rao Durbha <S.Durbha@cablelabs.com>
- CC: Mountie Lee <mountie@paygate.net>, Lu HongQian Karen <karen.lu@gemalto.com>, Arun Ranganathan <arun@mozilla.com>, "public-webcrypto@w3.org Working Group" <public-webcrypto@w3.org>
- Message-ID: <51893AC6.4010903@gmail.com>
Not sure to understand you, if something is compromised and you can not detect it, then you can not do anything against it, whether it's WebCrypto or any other API. Regards, Le 07/05/2013 19:18, Seetharama Rao Durbha a écrit : > 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 > 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 > -- 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 Tuesday, 7 May 2013 17:30:43 UTC