Ok, non-payment situation .... right out of previous email. in court of law ... involving civil litigation ... both parties have their own lawyers
ok, from SSL/TLS with TPP CA .... and mutual authentication; both parties have a TTP CA and both parties have certificates from their respective TTP CAs. Just as in the financial four corner model ... there are situations where the merchant bank and the consumer bank may be the same financial institution; in which case they refer to the transaction as "on us". The four corner model doesn't absolutely preclude a financial institution being the same for both parties .... but it operates in such a way that it allows that the merchant can be certified by one entity and the consumer can be certified by another entity ... and it isn't required as part of mutual authentication ... that the certifying agency be the same for both the merchant and the customer. The whole point of the detailed discussion of the merchant and the consumer in the four corner model was to show the chain of trust going in both direction. The chain of trust goes in both directions .... one for the merchant and one for the consumer .... in the financial four corner model The chain of trust tries to go in both directions .... one for the server and one for the client ... in the SSL/TLS mutual authentication four corner model. The problem in the TTP CA SSL/TSL (almost) PKI for mutual authentication .... is the server doesn't actually have any business relationship with the client's certifying body and the client doesn't actually have any business relationship with the server's certifying body, without valid business relationship and recourse ... there is only the facade of a trust network but one doesn't actually exist (in either direction). The TTP CA business model with stale, static certificates is actually even worse (note that a TTP CA model with online certification doesn't suffer from this horribly inverted business model). The client is paying the TTP CA for the client's certificate .... which exists for the benefit of the server (and in some cases the existance of a client certificate can actually be to the detriment of the client). The server is paying the TTP CA for the server's certificate .... which exists for the benefit of the client. Not only does the stale, static certificate paradigm have the exchange of value occur between the wrong parties .... but the exchange of value between the wrong parties lends itself to precluding a real network of trust being implemented. When the client pays for their own certificate to the client's TTP CA, for the server;s benefit, it precludes there being a valid business relationship and chain of trust between the server and the client's TTP CA. When the server pays for their own certificate to the server's TTP CA, for the client's, it precludes there being a valid business relationship and chain of trust between the client and the server's TTP CA. In the online (financial) four corner model, the server pays the client's TTP CA for certification of the client; that creates the basis for legal obligation between the client's TTP CA and the server for a valid chain of trust. The real, major difference between a 3-corner TTP CA and a four corner TTP CA .... isn't whether it is financial or not, it is whether there is mutual authentication/certification or only single authentication/certification. The real, major problem with TTP CAs implemented with stale, static certificates ... is it fails to create a legal relationship between the certification authorities and the relying parties. The server's TTP CA has no obligation to the client, and the client's TTP CA has no abligation to the server. Therefor there is no chain of trust, therefor it is just a pure fabrication about any real trust network. As previously noted. GSA attempted to overcome this total lack of the TTP CA model to any resumblance of valid business proposition by all of their contracts. It has been pretty well shown that any entity can sue any other entity. A merchant can sue a customer for fraud and a customer can sue a merchant for fraud. The issue is can a merchant sue a certifying body for anything at all with regard to what a customer does. Typically a merchant sueing a certifying body with regard to some customer's action is only to the extent that the certifying body has some obligation to a merchant. In a simple TTP CA stale, static certificate model, without a business relationship between the merchant and the consumer's TTP CA , no business relationship has been created between the consumer's TTP CA and the merchant. Therefor there is no grounds to sue. Similarly, a client sueing a certifying body with regard to some merchant's action is only to the extent that the cerifying body has some obligation to the client. In a simple TTP CA stale, static certificate model, without a business relationship between the consumer and the merchan'ts TTP CA, no business relationship has been created between the merchant's TTP CA and the consumer. Therefor there is no grounds to sue. All four corners exist in all situations when there is any kind of mutual certifying process between two parties; aka 1) PARTY A, 2) PARTY A's certification institutioon, 3) PARTY B, 4) PARTY B's certification institution. The horrendous problem in the traditional TTP CA stale, static certificate business model is that 1) no obligation is created between PARTY A's certification institution and PARTY B 2) no obligation is created between PARTY B's certification institution and PARTY A so no trust network ever actually exists. As been repeated pointed out in the past several posts, that is possibly one of the motificating factors in all of the GSA contracts with TTP CAs and relying-parties ... creating a valid basis for a trust network. Possibly there is some other assumptions that aren't being clearly understood. In general, certifying bodies exist when there is little or no reason for two totally complete strangers (that might have some business opportunity) for trusting each othter. Two entities that have some past business relationship may not feel they need independent certification authority. However, whether a certifying process is used or not doesn't preclude either party from performing some fraudulent act. This goes back to the whole original concept of these certification bodies in the first place, which is to establish trust when there is usually no other basis for trust. Trust doesn't elimiante fraud but it possibly lowers its probability. In the four corner, credit model there is quite a bit that is guarenteed. As previously pointed out, the merchant's financial institution is actually on the hook for merchant deliverying contracts goods or services or refunding money (as per the bankrupt airlines example). I don't understand the issue about the four corner model and identity fraud. A business model and obligations don't preclude fraud. They may somewhat lower its probability but it doesn't lower it. As been repeatedly mentioned in the past several posts, quite a bit of identity fraud is a shared secret issue. X9.59 is specifically targeted at 1) strongly authenticated transactions 2) elimination of the account number as a shared secret (and therefor as a subject of identity fraud) 3) elimination of additional identity information or shared secret information as a means of authenticating the transaction X9.59 is agnostic with respect to identification .... only performing authentication. However, X9.59 can contribute significantly to reduction in identity fraud by eliminating any requirement for shared-secret and/or identity information as part of the financial transaction. Furthermore, the X9.59 characteristic applies to 2-corner model, 3-corner model, and 4-corner model The issue of somebody's use of a 4-corner model as opposed to choosing a 2-corner model or a 3-corner model seems to have nothing at all to do with identity fraud issues. The business issues of 2-corner, 3-corner, and 4-corner business process implementations is almost totally orthogonal to the business issues related to identity fraud. The design of the transactions and the selection of what kind of information is required for the transactions can have a significant effect on identity fraud. My assertion is that the prevalence of identity fraud is at least partially a characteristic of the significant reliance on shared-secrets and identity related information in much of the deployed infrastructures today (totally independent of how many corners they may have). The further assertion (as in the X9.59 case), if it is possible to steal every piece of information in the transaction and still not perform a fraudulent transaction based on that information, several types of existing fraudulent activity would be eliminated. x9.59 references: http://www.garlic.com/~lynn/index.html#x959 repeated references to gsa contract: http://www.garlic.com/~lynn/aadsm12.htm#22 draft-ietf-pkix-warranty-ext-01 http://www.garlic.com/~lynn/aadsm12.htm#41 I-D ACTION:draft-ietf-pkix-sim-00.txt http://www.garlic.com/~lynn/aadsm12.htm#42 draft-ietf-pkix-warranty-extn-01.txt http://www.garlic.com/~lynn/aadsm14.htm#37 Keyservers and Spam http://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working" http://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process, payment, authentication and identification -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm [EMAIL PROTECTED] on 6/28/2003 3:32 pm wrote: I believe we are in agreement with what the fourth corner does in a trust network, it is like the relying party's insurance, link to the law, etc. A problem as I see it is what the fourth corner (or TPP CA) is prepared to vouch for in an non-payment situation. It can surely not make any warranties (in contrast to payments) about the value and credibility of the client, only that it has performed an RA and certification process according to some written practice statements. Does the RP need a business relation with the trust network in order to be able to sue a misbehaving client who is repudiating its actions? Some people claim that, I don't. If the signature can be technically derived to the client's key, the client is toast. Is the fourth corner is supposed to protect the RP from client key misuse/theft? I would say that this would be a very bad idea as the key may have been used to open information banks of incredible value that no insurance will cover and is not possible to rollback either. Authentication <> Payments! But if the faulty operation is due to certification errors, probably due to identity fraud? Then we enter the real CA liability scene. RP contracts have the same function as US SW licenses: To make you aware that nothing is really guaranteed, it is sold "as is". Is this acceptable? This is hard to say, it is rather depending on how frequent errors are and the consequences of those. A problem is that a fourth corner can do nothing about identity fraud which in my opinion makes it less viable regardless of its possible legal value. So of course it is good to have business relations between parties in a trust network, but don't expect to get compensation when things go REALLY wrong. It is also rather hard to run court trials regarding information theft as it is hard to put a value on copied information. Due to these problems I believe the fourth corner is something that bank-operated trust networks should not take for granted. Particularly if it causes business parties to pay for received messages rather than (or in addition to) for sending messages.
