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

Re: Web Cryptography Use Cases For Review

From: Arun Ranganathan <arun@mozilla.com>
Date: Wed, 3 Apr 2013 14:22:40 -0400
Cc: "public-webcrypto@w3.org Working Group" <public-webcrypto@w3.org>
Message-Id: <7CFCAD50-C360-4A2C-9498-3EB9B8FC9390@mozilla.com>
To: Mountie Lee <mountie.lee@mw2.or.kr>
Hi Mountie!


On Mar 31, 2013, at 8:06 PM, Mountie Lee wrote:

> Hi.
> following is the description for banking usecase.
> it is described by considering certificate that the draft is not yet posted WG.
> so code example is missing.
> 
> by getting consensus for certificate, the usecase description can be modified later.
> 
> PS) HongGilDong is traditionally more famous than PSY.
> -----------------------
> HongGilDong want to issue certificate that will be used online banking.
> he visit physical bank branch
> and retrieve reference number and approval code by face to face verification of bank staff.
> the reference number is used to track certificate enrollment process for multiple days.
> 
> HongGilDong visit bank website (ra.gangnambank.com)
> he generate key pair
> and send the public key, reference number, approval code and other parameters to bank RA(Registry Authority) center.
> bank RA server forward the request to CA and return the certificate signed by CA to user agent of HongGilDong
> 
> when he want to wire fund online
> he enter some authentication codes (OTP, password or other authentication methods promised between bank and account holder)
> he generate digital signature for agreement document with his private key binded to certificate issued by trusted CA
> also he envelop the signed document with certificate of bank
> and send enveloped message to bank
>  
> when he want to revoke certificate,
> he generate digital signature for revoke request document with his private key
> also he envelop the signed document with certificate of bank.
> and send enveloped message to bank.
> bank forward the revoke request to CA
> CA add the certificate to CRL that will be check later by CRL Distribution Point of certificate

Is what you've discussed above a description of the *system as it works now* in Korea?  

I actually think that in-browser storage along with asymmetric key generation, key (un)wrapping, signing and verification might be enough of an API footprint to address the kind of transaction described above. 

I think your use of "enveloped messages" above might actually be a  good use case for key (un)wrapping (if I've understood it correctly), which I think this WG is addressing.  In fact, the notion of certificates above might actually be an imposition on users, who might benefit from a simplified approach to things.

-- A*
Received on Wednesday, 3 April 2013 18:23:11 UTC

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