W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2013

Re: Additional use cases

From: Aymeric Vitte <vitteaymeric@gmail.com>
Date: Thu, 09 May 2013 23:04:46 +0200
Message-ID: <518C0F6E.3010307@gmail.com>
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>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:17 UTC