Re: Additional use cases

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> 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> 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> 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> 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> 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> 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
>>
>>   =======================================
>> 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
>
>   =======================================
> 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
>
>


-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World