- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Thu, 09 May 2013 23:04:46 +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: <518C0F6E.3010307@gmail.com>
I don't see where is the contradiction between what I wrote and your reply... Regards, Le 08/05/2013 04:15, Mountie Lee a écrit : > I meant > for public-private key pair in current WebCrypto API spec, > I have no objection for silent operation and the keys can be owned by > provisioners. > > but > > for certificate-private key pair, > I have objection for silent operation. > because > at least as my understanding, > the client certificate is issued to individual and it's paired private > key is owned my user. > the private key should not be accessed without user permission. > that means non-silent operation. > > PIN or passphrase can be used for getting user permission. > > I have mentioned previously that > users always click "yes" on simple questions like installing binary > plugins. > but > PIN or passphrase is different from simple "yes" clicking. > > regards > mountie. > > On Wed, May 8, 2013 at 2: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:02:22 UTC