Anders Rundgren wrote: > Absolutely! However, there is no infrastructure in place for that. > > Another reason for the PKI solution is that the financial sector > (which you always refer to) has turned out to be the only remaining > survivor on the client certificate market here not counting low-value > e-mal certs. > > The market is mainly consisting of governments who desperately > need to reduce costs for adminstration. It is hard to see that > anything but a 1-to-many ID TTP solution would fit that scenario. > > But this PKI is usually based on contracts so it fits your view on > how a CA should operate. I believe both banks and governments > should go to an open subsriber-based model as it will long-term > be most profitable/cheapest. That is, CA liability is IMHO an > overrated issue. By having banks use their own stuff, they have > all the reasons for doing the right thing. > > Assume you are losing your ID on the wrong side of the > globe. How would anybody but the financial sector be > able to handle this? VeriSign? Not a chance.
there are several infrastructures in place for that. in the mid-90s, one of the pki oriented payment structures had the financial insitutions registering public keys and issuing relying-party-only certificates. the issue wasn't the registering the public keys ... since the financial insitutions have well established relationship management infrastructures. the problem was trying to mandate that simple improvement in authentication technology be shackled to an extremely cumbersome and expensive redundant and superfluous PKI infrastrucutre. the other issue ... was that the horribly complex, heavyweight and expensive PKI infrastructure had limited their solution to only addressing evesdropping of transactions "in-flight" ... which was already adequately addressed by the existing e-commerce SSL solution http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm3.htm#asrn3 http://www.garlic.com/~lynn/subpubkey.html#sslcert and was providing no additional improvement in the integrity landscape. so you have a simple and straight-forward mechanism for minor technology improvement in authentication ... schackled to a horribly complex, expensive, redundant and superfluous PKI operation which was providing no additional countermeasures to the major e-commerce threats and vulnerability (than the existing deployed SSL solution). Now if you were a business person and was given an alternative between two solutions that both effectively addressed the same subset of e-commerce vulnerabilities and threats ... one the relatively straight-forward and simple SSL operation and the other a horribly complex, expensive, redundant and superfluous PKI operation .... which would you choose? An additional issue with the horribly complex, expesnive, redundant and superfluous PKI based solutions were the horrible payload bloat represented by the relying party only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo was that the typicaly payment message payload size is on the order of 60-80 bytes ... the attachment redundant and superfluous relying-party-only digital certificates represented a payload size on the order of 4k-12k bytes .... or a horrible payload bloat increase by a factor of one hundred times. As mention in the previous posting, the x9a10 financial standard working group which was tasked with preserving the integrity of the financial infrastructure for all retail payments actually attempted to address major additional threats and vulnerabilities with x9.59 http://www.garlic.com/~lynn/index.html#x959 and there was actually a pilot project that was deployed for iso 8583 nacha trials ... see references at http://www.garlic.com/~lynn/index.html#aads part of the market acceptance issue is that the market place has been so saturated with PKI oriented literature .... that if somebody mentions digital signature ... it appears to automatically bring forth images of horribly expensive, complex, redundant and superfluous PKI implementations _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
