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

Re: Additional use cases

From: Mountie Lee <mountie@paygate.net>
Date: Wed, 8 May 2013 00:44:17 +0900
Message-ID: <CAE-+aYK4rqjwW1m2JxJ1j60OTHjmd=XG5OyRPUGOCqNiaf7AAQ@mail.gmail.com>
To: Seetharama Rao Durbha <S.Durbha@cablelabs.com>
Cc: Lu HongQian Karen <karen.lu@gemalto.com>, Arun Ranganathan <arun@mozilla.com>, "public-webcrypto@w3.org Working Group" <public-webcrypto@w3.org>
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

Received on Tuesday, 7 May 2013 15:45:06 UTC

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