Ram A Moskovitz <[EMAIL PROTECTED]> writes: > I wonder why Mastercard/VISA didn't and don't choose to run > everything themselves in house.
Mastercard/VISA are brand associations. also when they started, there were possibly 30k banks issuing and acquiring credit cards ... each with their own processing. basically there are two variables for four possible conditions: * physical and offline * physical and online * electronic and offline * electronic and online when things first started, the operation was physical (plastic card) and offline (paper processing). there were invalidation booklets that were mailed to all merchants monthly containing all invalid/revoked/etc account numbers. To some extent the CRLs defined for PKIs were modeled after the physical and offline paradigm invalidation booklets from the 60s. The CRLs also somewhat differentiate a PKI operation from a purely *certificate manufactoring* infrastructure ... a term we coined in the mid-90s when we started working with this small client/server startup that wanted to do payments http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 The problem with the 50s & 60s paradigm was the inability for the CRL paradigm to scale-up ... the numbers of invalid accounts were increasing dramaticly (and therefor the aggregate risk from invalid accounts) and the number of merchants were increasing dramatically. The result was that you had to send out much larger booklets to a much larger number of merchants on a much more frequent interval (i.e. risk is in part proportional to the distribution interval). Pretty soon you were looking at dristributing booklets with thousands of pages to millions of merchants every couple of hrs. Now the niche that the Certificatin Authorities, PKIs, and digital certificaes fit into is the "electronic and offline" paradigm. The payment industry bypassed that archaic step and went directly to electronic and online; a magnetic stip was put on the same plastic card and infrastructure was deployed to perform real-time, online transactions. Not only did they get real-time authentication and authorization but they were also able to get operations dependent on data aggregation (like credit limit, patterns of useage that indicate fraud patterns). The PKI model with a stale, static digital certificate would have had them imprinting the physical card ... with the card's credit limit ... but the stale, static digital certificate PKI model has no mechanism for indicating outstanding charges and/or whether the aggregate of past transactions exceed the credit limit. Somewhat after we had worked on this thing that has since come to be called electronic commerce ... there were a number of people suggesting that credit card transactions could be moved into the modern world by having card owners digitally sign the transaction and attached a digital certificate. Our observation was that the digital certificate attachment would have actually regressed the payment transactions by 20-30 years to the 50s ... as opposed to moving it into the modern environment. The x.509 identity certification business of the early 90s was starting to wonder what information a business or relying party might actually need about the person ... not being able to accurately predict what information might be needed, there was some direction to grossly overload identity certificates with enormous amounts of personal information ... in hopes that a relying party or business might find some information in the certificate of some use. By the mid-90s, some number of institutions were starting to realize that x.509 identity certificates, grossly overloaded with enormous amount of personal information represented significant privacy and liability issues. As a result, you started to see some appearance of relying-party-only certificates http://www.garlic.com/`lynn/subpubkey.html#rpo which basically only contained some sort of repository lookup value (a repository that contained all the real information) and a public key. However, it is trivial to show that such an implementation both violates the original design point justifying PKIs and digital certificates but that they were also redundant and superfluous. Now with regard to the association brands. As the transition of the payment card industry to a realtime, online processing model (as opposed to the archaic offline processing model represented by PKIs, certification authorities and digital certificates), an emerging requireming was that all of the independent bank processing operations needed to be interconnected. So one of the things that you started seeing appearing was the assocations deploying in the 70s and 80s was a value added network (in general, value added networks saw a big increase in the 80s ... but have since somewhat died off, having been obsoluted by the internet). The band associations have maintained their value added network infrastructure ... even in the face of the internet having generally obsoleted most other value added network operations. The current processing outsourcing to is not by the brand associations ... which still operate their value added networks to tie together the multitude of bank datacenters (getting realtime transactions from the merchant bank to the consumer bank and back) ... but by the banks ... where they have outsourced their whole processing operation. In this situation, it is different from outsourcing certification and trust ... separated from the actual transaction processing (which simple security theory indicates can lead to fraud) ... but all aspects of the online, realtime processing has been outsourced. So looking at a digital certificate related scenario ... the ssl certificates http://www.garlic.com/~lynn/subpubkey.html#sslcert this small client/server startup that wanted to do payment transactions (which is now frequently referred to as electronic commerce) had this stuff called SSL that was to be used in the payment processing. So as part of the deployment we had to go around and audit the major institutions called certification authorities (this is when we coined the term *certicate manufactoring* to distinguish the operations from the thing that is commonly called PKI in the literature). so the justification for SSL certificates was because of percieved integrity weaknesses in the domain name infraustructure and the possibility that a client might be talking to a webserver different than the webserver they thought they were talking to. So a merchant applies for a SSL digital certificate for their webserver internet name. Then in the SSL protocol ... the browser validates the webservers SSL digital certificate and then compares the webserver name that the client typed in against the name in the digital certificate. It turned out there are a couple problems. A lot of merchants found out that using SSL cut their webserver performance by 80-90percent. As a result they started only using SSL for the payment/checkout phase of shopping. The problem is that the browser no longer checks what the client typed in against a SSL certificate. When the client gets around to payment/checkout, they click on a button ... that does the URL stuff automatically. Now if the client had been visiting a fraudulent/incorrect website site (which SSL is designed to prevent), such a fraudulent website is likely to have their payment/checkout button specify a URL for a website name for which they have a valid certificate (defeating the original purpose for having SSL). Another issue is that most certification authorities aren't actually the authoritative agency for the information being certified (which, in turn, the digital certificate represents that certification business process). In the SSL scanario, the SSL certification authorites have to check with the authoritative agency for domain name ownership. An issue is that the authoritative agency for domain name ownership is the domain name infrastructure ... which has the original integrity issues justifying the use of SSL. So somewhat backed by the SSL certification authority industry, there has been a proposal that domain name owners register a public key for their domain name ... and all future correspondance is digitally signed by the corresponding private key. The domain name infrastructure then can retrieve the onfile public key to verify the digital signature (as countermeasure against various fraudulent manipulation of the domain name infrastructure) ... not this is a certificateless operation: http://www.garlic.com/~lynn/subpubkey.html#certless There is also some additional benefit to the SSL certification authority industry; they can replace the time-consumer, expensive and error prone process of acquiring identification information from the SSL certificate applicant and attempting to match it against the identification information on file in the domain name infrastructure. Instead they can have a much simpler, reliable and less expensive authentication process ... where the SSL certificate applicant digitally signs their application and the SSL certification authority retrieves the onfile public key from the domain name infrastructure and validates the digital signature: http://www.garlic.com/~lynn/2005o.html#40 Certificate AUthority of a secured P2P network Unfortunately this represents something of a catch22 for the SSL certification authority industry 1) increasing the integrity of the domain name infrastructure lessens the original justification for having SSL digital certificates 2) if the SSL certification authority industry can base their whole trust root on using onfile public keys for digital signature verification (totally certificateless), it is possible that the rest of the world could start also doing real-time, online retrieval of onfile, certificateless public key operation. One could even imagine a highly optimized, certificateless SSL protocol ... where the response to the hostname not only carried the ip-address but also piggybacked any available public key and any other applicable SSL protocol information (in the same transaction). Then in the initial client session setup with the webserver ... they can include the (public key) encrypted symmetric session key and the actual request. The webserver then can both do session setup and process whatever request in single operation. Here is a scenario where improved integrity can bring any outside certification operation intended for an offline environment back in house ... drastically simplifying all aspects of the operation, moving to an online, real-time paradigm, and improving overall integrity. -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
