Re: Additional use cases

I don't think so, but, again, what is the point here? If you are 
compromised, nothing can save you.

Regards,

Le 08/05/2013 04:17, Mountie Lee a écrit :
> for ensuring script integrity,
> we can use the suggestions of webappsec WG's CSP.
>
>
>
> On Wed, May 8, 2013 at 2:18 AM, Seetharama Rao Durbha 
> <S.Durbha@cablelabs.com <mailto:S.Durbha@cablelabs.com>> wrote:
>
>     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  <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:09:53 UTC