Re: Banking Transaction Use Cases

for certificate enrollment, it need sequence of operations.

followings are the normal process in Korea.

a) bank account holder visit physical bank office to issue digital
certificate
b) bank staff verify user identity by face to face meeting with ID card.
c) bank staff give a token to user (the token is generated from bank RA
system)
d) user visit CA center(web site) and enter token and some other account
related information
e) private and public keys are generated by CA software ( normally ActiveX)
f) CA software send Request to Issue Certificate message to CA server
g) CA verify the token and other informations
h) CA software receive the certificate and install to user agent or other
internal keystore.

the above processes are defined by CMP international standard (
http://en.wikipedia.org/wiki/Certificate_Management_Protocol )

by WebCrypto API, we need to re-define whole processes and comparing the
differences and possibilities.


On Thu, Dec 20, 2012 at 11:00 AM, Arun Ranganathan <aranganathan@mozilla.com
> wrote:

> Hi Anders :)
>
> ----- Original Message -----
> > On 2012-12-18 23:13, Arun Ranganathan wrote:
> > > Hi Anders :)
> > Hi Arun,
> > Thanx for the response!
> >
> > I think this issue is related to another thorny discussion: Why
> > doesn't banks use <keygen>?
>
>
> In this particular case, I think <keygen> shouldn't really be used too
> much at all by *anyone.*  I don't think it's a good idea, and I think that
> the webcrypto api should replace keygen over the long term.
>
> For instance, try:
> https://bug474958.bugzilla.mozilla.org/attachment.cgi?id=380749 in
> Firefox, Chrome, Opera, IE, and Safari.
>
> You'll see that the markup used to create that page is very similar.  But
> note the variation in the drop down field!  It varies across the board
> depending on what browser you've chosen.  And, the higher the bit "grade"
> the longer the computation.  It is clearly something that can lock up the
> main thread.  And also notice how IE10 in Widget mode on Windows 8 behaves.
>
> I'd say keygen doesn't demonstrate interoperability, and thus is a bit
> flawed.  When implemented properly, it shows a one-time key generation,
> submitted via a form.  This itself isn't great (at it's worst, it is simple
> HTTP; at it's best, it uses TLS, but not Diffie Hellman Key Exchange).
>
>
> >
> > I have tried (for years actually...) bringing up this topic but it
> > always fail because the US vendors do the assumption that the EU and
> > Asian bank-people simply are "morons".
> > That may be true but unfortunately <keygen> is "useless" using their
> > thinking.
> >
> > It is obvious that there simply MUST be a link between real bank
> > technology [*] as featured in Google's Wallet, <keygen>, and the Web
> > Crypto API but this not only out-of-scope, it is actually not even
> > discussable due to IPR considerations.
>
>
> I think we should talk about real encryption technology, for multiple
> sectors, including banking :)  I'm not sure keygen in HTML5 is used by
> Google Wallet.  I think we're on our way to something with the WebCrypto
> API. My first draft of the banking use case doesn't touch certificates, but
> it does touch on assymetric keys, including longer lasting assymetric keys
> in IndexedDB.  That's a start :-)
>
> Cc'ing David Dahl to keep me honest.
>
> -- A*
>
>
>
>
>


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