Re: "Korean bank" use-case - Rejected?

On 2011-12-09 16:42, Channy Yun wrote:
> 2011/12/8 Anders Rundgren <anders.rundgren@telia.com>
> 
>> This use-case (in order to be meaningful) covers all aspects of a key's
>> life:
>> from enrollment, to usage, renewals and revocation.
>>
> 
> This can be separated primary and secondary area. Mos impoartant part of
> Korean use-cases is generationg of *digital signature* with user
> certificate in anywhere. Key management can be served by third party
> extensions or oneself in key manament option in browers.

Well, since neither platform vendors like Microsoft, Government bodies like
NIST (FIPS 201/PIV), smart card manufactures like Gemalto, payment networks
like VISA, or the Financial Industry have come up with any kind of *open*
proposal for token provisioning using browsers, I will at least personally
stick to this topic.

   Token Provisioning <<>> Certificate Enrollment

*Physical distribution of credentials belongs to the past*.  With the
nowadays fully implemented "Mobile Internet" this is notion is what
counts, *also for banking*.  Currently organizations have to "standardize"
on a particular device/brand in order to enable their mobile employees
and clients.  This is clearly not in the interest of the market!

My since long running project[1] is an attempt bridging "artificial"
gaps like embedded vs. connected tokens, payments vs. authentication,
and certificates vs. information cards.

Digital signatures in browsers is cool but the need for standardized
token provisioning is probably 2-3 magnitudes bigger.

However, as I have iterated before, there is no SDO that could take on
token provisioning (it is too "political"), so a digital signature project
may be exactly what is called for!  I would recommend looking into the
WASP specification[2] which adds several important things missing in
the current proposals like credential filtering and signature profiles
(a signature scheme that doesn't support PDF would IMO be useless).
BTW, OASIS DSS-X has recently started a client signature effort[3].

Anders

[1]
http://webpki.org/papers/keygen2/sks-keygen2-exec-level-presentation.pdf

[2]
http://www.webpki.org/papers/wasp/wasp-tutorial.pdf

[3]
http://lists.oasis-open.org/archives/dss-x/201111/msg00001.html

> 
> 
>>
>> I do not think this group is properly equipped to deal with such a wide
>> scope
>> but if somebody wants to take it up, please do!
>>
> 
> If someone can afford to try to do, I think it can be do this in working
> group too. Many crypto-geeks can be volunteers. BTW, where is VeriSign? :)
> 
> 
>>
>> Experiences from other consortium's like the Information Card Foundation
>> indicates that the interest in publicly dealing with on-line banking
>> technology
>> is moderate; it has always been a "consultant paradise".
>>
> 
> You're right. There are many companies to support banks technically in
> Korea too. But, many counties have already "law" for digital signature,
> http://en.wikipedia.org/wiki/Digital_signatures_and_law. It means it's
> standards area in web applications too.
> 
> Channy
> 
> 
>>
>> Just adding a seemingly smallish thing like a PIN-code to a credential
>> actually
>> has huge implications that no open SDO has *ever* even tried addressing.
>>
>> Anders
>> turning into lurking mode only
>>
>>
>>
>

Received on Saturday, 10 December 2011 06:39:09 UTC