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

Re: Additional use cases

From: Aymeric Vitte <vitteaymeric@gmail.com>
Date: Tue, 07 May 2013 19:15:15 +0200
Message-ID: <518936A3.2010609@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>
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

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