- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Tue, 07 May 2013 19:15:15 +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: <518936A3.2010609@gmail.com>
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
Received on Tuesday, 7 May 2013 17:13:07 UTC