"Anders Rundgren" <[EMAIL PROTECTED]> writes: > If this list believe that users should do conscious decisions on > what CAs to trust you are on the wrong track as this is impossible > to do for mere mortals. A possible solution would be that you for a > fee "outsourced" CA trust decisions to a party that have this as > their prime business. Such a model would in fact add considerably > more interesting stuff to the plot than just CA validity. It could > actually claim that a reputation of an organization your are about > to contact is not the best.
trust is a funny thing. in the non-association payment card world ... each merchant that accepts payment card has a bilaterial agreement (aka contract) with each financial institution issueing cards (for which they accept/trust cards, aka NXM contracts, aka N merchants, M issuers). in turn, each financial institution issueing cards has effectively bilaterial agreement with the consumers they issue a card for. for ten thousand merchants, a thousand issuing institutions, and a million customers ... for merchant having contract with every issuing institution, it would be 10K*1K contracts (on the merchant side) and 10**6 on the issueing side. this avoids the larger problem of ever merchant having a contract with every customer with a payment cards (or even for each of a customer's payment card). in the association payment card world ... the contract problem is slightly simplified. a merchant has a contract with their merchant financial institution (one per merchant). A merchant financial institution has a contract with the association (one per merchant financial institution). A consumer has a contract for each one of their payment cards with the respective card issuing financial institutions. Each card issuing financial institution has a contract with the association. Basically there is three level hierarchy of trust & contractual relationship. This mitigates the worst case scenario of having ever customer sign a trust/contract with ever merchant (say worst case with billion customers and a million merchants ... having a million, billion contracts). The other characteristic that carries thru via the financial institution contracts with the assocations, is that the merchant financial institution is liable to the assocation on behalf of the merchants they sponsor ... and consumer financial institution is liable to the association on behalf of consumers they issue cards to. The merchant example, is that merchant financial institutions both love & hate big ticket merchants like airlines; they love the percent charges they get one the big ticket transactions for accepting the liability ... but it is painful with an airline goes bankrupt and they have to make good on all outstanding charged tickets (which frequently has run to tens of millions). The typical TTP CA trust model (from a business standpoint) is interesting ... since there are explicit trust/contract typically between the CA and the key owners that they issue certificates to. However, their frequently is no explicit trust/contractual relationship that traces from relying parties to the CA (as you would find in the financial world that traces a trust/contractual trail between every merchant and every constumer issued a payment card, aka a merchant can trust a payment card via the thread of contracts thru their merchant financial institution, to the association and then to the card issuing consumer financial institition, with a corresponding thread of explicit liability at each step). In the federal PKI model ... they sort of made up for this by having GSA (as a representative of the federal gov. as a relying party) sign contracts with every approved CA issuing certificates. That way the federal gov. (as a relying party), when accepting a certificate and making some decision or obligation based on the trust in that certificate ... has a legal liability trail to the certificate issuing institution. In the SSL certificate model, when a client/end-user makes any decision or obligation based on the trust in the SSL certificate, it is rare that every client/end-user has a contractual trail back to the SSL certificate issuing institution. In the payment card world, the merchant accepting a payment card has a contractual trail to the responsible financial institution accepting liability on behalf of the consumer they issued a card to. In a similar way, each consumer presenting a card to a merchant has a contractual trail to the responsible financial institution accepting liability on behalf of the merchant they represent. When a merchant presents an SSL certificate to a consumer ... the consumer has no contractual trail to the SSL certificate issuing institution. In the early development of this stuff that became to be called e-commerce http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/addsm5.htm#asrn3 there was some look at the business issues of payment associations issuing branded SSL certificates ... so that the presentation of such a branded SSL certificate carried with it trust/liability obligations similar to the branded association decals you see on physical store fronts. One problem was what might be impled by placing trust in an SSL certificate (and therefor the associated possible liabilities) are quite a bit more ambiqutous than what is defined for trust between merchant & consumer in a payment card transaction. If all such branded SSL certificate were only to explicitly cover the actual payment transaction and no other activity ... then it was much easier to define the liability issues (aka there are contractual/business issues that tend to be orthogonal to technical protocol issues ... and people working on technical protocol issues may not even have any concept of what they are about). One of the issues has been that many merchant financial institutions were having a hard time even coming to grips with reality of signing contracts allowing internet merchants to be credit card enabled. They could see it for brick&morter institutions that already are "MOTO" authorized (i.e. internet credit card transactions mapping into the existing non-face-to-face, credit-card holder not present contractual parameters of "mail-order/telephone-order" transactions). The issue was for a purely internet merchant that had no inventory, no physical property ... etc. ... no assets that could be forfeited in the event of a bankruptcy that would cover the risk exposure to the financial institution for taking liability of all possible outstanding transactions. The other charactistic of CA PKI certificate paradigm being targeted at the early 80s, offline email paradigm ... was that in the payment card scenario every merchant transaction is online and passes thru the (liability accepting) merchant financial institution (or some agent operating on behalf of the merchant financial institution). The CA PKI certificate paradigm for the early 80s, offline email had the relying-party/recipient dialing their (electronic) postoffice, exchanging email, hanging up, and being faced with first-time communication from a total stranger ... where the relying-party had no other recourse for establishing any attributes regarding the stranger. The PKI certificate was sort of filled an analogous role to the "letters of credit" from the sailing ship days. This is an offline push model where the subject is pushing the credential to the relying-party ... and the intended purpose was to address the environment where the relying-party had no real-time method for corroborating the information. In the 90s when some suggested that the credit card model should be brought into modern era with certificates; I would comment that it would be regressing the payment card industry to the archaic, ancient non-electronic period of the '50s & '60s (when the merchant, relying-party had no recourse to online information and had to rely on the revokation booklets mailed out every month, and then every week). The payment card industry transitioned to the online model in the 70s and left the old fashion offline model (that the CA PKI model uses) mostly in history. In any case, the issue for the merchant financial institution, accepting liability on behalf of the merchant gets to see every financial transaction in real time as it is happening. At any point in time, the merchant financial institution has an approximate idea of the aggregate, outstanding fianncial liability it has per merchant (because it is seeing and aggregating the transactions in real time) and had the ability to shut it all down at any moment. One of the financial institutions objections to the CA PKI certificate model ... was that there could be an incremental financial liability every time the merchant presented the certificate ... and there was no provisions for an issuing financial institution (that chose to stand behind such a paradigm) to calculate their potential, outstanding risk. The issue of not knowing their potential liability exposure at any moment was somewhat othogonal to not knowing how to deal with operations that might not having any assets ... and therefor there was nothing to recover in forfeiture if a bankruptcy occured. That was somewhat the idea that CA PKI certificates ... in the modern online risk management world ... was ideally suited for no-value transactions (i.e. since the trust issue involved no value ... it would be easy to always know the oustanding, aggregated risk ... since you knew that summing values of zero ... still came up zero, no matter how many such events there were). - Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
