Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes: > 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).
using the non-association & non-merchant bank example ... then if SSL TTP PKI CAs were to apply normal business processes ... then every relying party for an SSL domain name server certificate would need to have a pre-existing contract with every SSL domain name server certificate issuing institution. Looking in a typical browser repository of trusted CA public keys ... there are possibly 40-50 (although some are multiples for the same business operation). Taking one billion internet clients as first order approximation to estimated SSL domain name certificate relying parties ... then gross, first under approximation to required number of such contracts would be 50 billion individually signed contracts. in the payment card scenario this is mitigated by having the credential (payment cards) issuing institutions sign contracts with the brand associations (hiearchical legal trust rollup on the issuing side). Then the relying-party merchants have contracts with merchant financial institutions which in turn rollup with the merchant financial institutions having (legal trust) contracts with the payment associations. in this sense, SSL TTP PKI CAs are more efficient than an approximately analogous real business operation (aka payment cards as issued credentials which require explicit business processes between all the parties) by eliminating conforming to standard business practices having explicit legal trust relationship between the relying parties and the credential issuing institutions. An example where this was addressed has been in the Federal PKI .. where the federal gov., as a relying party, signed explicit (legal trust) contracts with each authorized certificate issuing certification auhtority. one of the things on the table (when originally pulling together the current e-commerce infrastructure) was that the same finanical infrastructure that took liability for merchant transactions would also issue SSL domain name certificates (which in addition to prooving domain name ownership would also indicate the liability accepting relationships). However, for whatever reasons, that option was not followed. The current scenario is that the SSL domain name certificates basically represent some due dilligence in checking with the domain name infrastructure as to the true domain name owner. However, there is (nominally) no related, explicit, contractual chain of legal trust that can be followed from relying parties to the certificate issuing operations. Also, as oft repeated one of the motivating factors in the perceived need for domain name due dilligence has been integrity concerns with regard to the domain name infrastructure .... and how can a client really be sure that the server they are talking to is actually the real server related to the domain name they typed in as part of the URL. This somewhat becomes somewhat ambiguous when one realizes that the domain name infrastructure is the authoritative agency for domain name ownership ... and the same authoritative agency that certification authorities have to check with regarding true domain name ownership. misc. past ssl certificate postings: http://www.garlic.com/~lynn/subpubkey.html#sslcert -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
