"Anders Rundgren" <[EMAIL PROTECTED]> writes: > 3D Secure (a.k.a. VbV) is an interesting twist to this as it really > (under the user's "supervision") connects the merchant and the card- > holder's bank for getting as fresh information there can probably > be. Also relying on PKI. Scales incredible well as you only need > one cert per bank and CC brand.
Are you saying that the PKI scales or the infrastructure scales? It would appear to be a descaling of PKI ... since there is only "one cert per bank". It is also has some number of operations that could be considered antithetical to the PKI design point. The consumer bank and the consumer have a predefined relationship. It is possible for the consumer bank to ship their public key for direct installation in the consumer's trusted public key repository. The PKI design point has trusted third party CAs ... installing their public key in the consumer's trusted public key repository ... the original model from the original electronic commerce http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 with this thing called SSL. The CA's then digitally signed digital certificates for operations that the consumer had no prior relationship with. The consumer could validate the digital certificates with the "CA" public keys on-file in their local trusted public key repository (possibly manufactored and integrated into their application, like a browser). For predefined relationship between a consumer and their financial institution ... they can exchange public keys and store them in their respective trusted public key repositories (a financial institution can provide the consumer some automation that assists in such an operation). PKI would appear to actually make the existing infrastructure less secure ... rather than the consumer directly trusting their financial institution ... the consumer would rely on a TTP CA to provide all their trust about their own consumer financial institution. In the mid-90s there was work done on PKI for payment transactions. One of the things learned from the early 90s, x.509 identity certificates ... was that they appeared to represent significant privacy and liability issues. As a result many institutions retrenched to relying-party-only digital certificates ... http://www.garlic.com/~lynn/subpubkey.html#rpo that contained little more than some sort of database lookup value (like an account number) and a public key. however, it was trivial to demonstrate such certificates were redundant and superfluous. One possible reason for the ease in demonstrating that such stale, static certificates were redundant and superfluous was that they appeared to totally violate the basis PKI design point, aka requiring a independent, trusted third party to establish trust between two entities that never previously had any interaction. For two parties that have pre-existing relationship, it is possible for them to directly exchange public keys and store them in their respective trusted public key repositories .... and not have to rely on a trusted third party to tell them whether they should trust each other. In the case where a consumer's financial institution is the only entity with a public/private key pair ... it is possible for the consumer to obtain the public key of their trusted financial institution ... not needed to rely on some independent third party to provide them with trust. The other issue from the mid-90s in the PKI-oriented payment transaction specification ... was that besides using redundant and superfluous stale, static certificates ... they also represented enormous payload bloat for the financial infrastructure. The typical iso 8583 payment transaction is on the order of 60-80 bytes. The RPO-certificate overhead for the operation was on the order of 4k to 12k bytes. The stale, static, redundant and superfluous digital certificate overhead represented an enormous, one hundred times increase in payload bloat. Another other question ... are you saying that the complete transaction goes via this new path ... or does the existing real-time iso 8583 transaction have to be performed in addition to this new real-time function have to also be performed (at least doubling the number and overhead for real-time operations). The existing iso 8583 operations goes as straight-through processing in a single real-time round trip. Does the introduction of these new operations improve on the efficiency of that existing single round-trip, straight through processing? -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
