Ed Reed wrote: > > >>> Ian Grigg <[EMAIL PROTECTED]> 12/20/2003 12:15:51 PM >>> > > >One of the (many) reasons that PKI failed is > >that businesses simply don't outsource trust. > > Of course they do. Examples: > > D&B and other credit reporting agencies. > SEC for fair reporting of financial results. > International Banking Letters of Credit when no shared root of trust > exists. > Errors and Ommissions Professional Liability insurance for consultants > you don't know. > Workman's Compensation insurance for independent contractors you don't > know.
Of course they don't. What they do is they outsource the collection of certain bases of information, from which to make trust decisions. The trust is still in house. The reports are acquired from elsewhere. That's the case for D&B and credit reporting. For the SEC, I don't understand why it's on that list. All they do is offer to store the filings, they don't analyse them or promise that they are true. They are like a library. International Banking Letters of Credit - that's money, not trust. What happens there is that the receiver gets a letter, and then takes it to his bank. If his bank accepts it, it is acceptable. The only difference between using that and a credit card, at a grand level, is that you are relying on a single custom piece of paper, with manual checks at every point, rather than a big automated system that mechanises the letter of credit into a piece of plastic. (Actually, I'm totally unsure on these points, as I've never examined in detail how they work :-) Insurance - is not the outsourcing of trust, but the sharing of risks. Unfortunately, most of the suppliers of these small factors in the overall trust process of a company, PKI included, like to tell the companies that they can, and are, outsourcing trust. That works well, because, if the victim believes it (regardless of whether he is doing it) then it is easier to sell some other part of the services. It's basically a technique to lull the customer into handing over more cash without thinking. But, make no mistake! Trust itself - the way it marshalls its information and makes its decisions - is part of the company's core business. Any business that outsources its core specialties goes broke eventually. And, bringing this back to PKI, the people who pushed PKI fell for the notion that trust could be outsourced. They thus didn't understand what trust was, and consequently confused the labelling of PKI as trust with the efficacy of PKI as a useful component in any trust model (see Lynn's post). > The point is that the "real world" has monitized risk. But the > crytpo-elite have concentrated too hard on eliminating environmental > factors from proofs of correctness of algorithms, protocols, and most > importantly, business processes. I agree with this, and all the rest. The no- risk computing school is fascinated with the possibility of eliminating entire classes of risk, so much so that they often introduce excessive business costs, which results in general failures of the whole crypto process. In theory, it's a really good thing to eliminate classes of attack. But it can carry a heavy cost, in any practical implementation. We are seeing a lot more attention to opportunistic cryptography, which is a good thing. The 90s was the decade of the no-risk school, and the result was pathetically low levels of adoption. In the future, we'll see a lot more bad designs, and a lot more corners cut. This is partly because serious crypto people - those you call the crypto-elite - have burnt out their credibility and are rarely consulted, and partly because it simply costs too much for projects to put in a complete and full crypto infrastructure in the early stages. > Crypto is not business-critical. It's the processes its supposed to be > protecting that are, and those are the ones that are insured. > > Legal and regulatory frameworks define how and where liability can be > assigned, and that allows insurance companies to factor in stop-loss > estimates for their exposure. Without that, everything is a crap > shoot. > > Watching how regulation is evolving right now, we may not see explicit > liability assignments to software vendors for their vulnerabilities, > whether for operating systems or for S/MIME email clients. Those are > all far too limited in what they could offer, anyway. > > What's happening, instead, is that consumers of those products are > themselves facing regulatory pressure to assure their customers and > regulators that they're providing adequate systematic security through > technology as well as business policies, procedures and (ultimately) > controls (ie, auditable tests for control failures and adequacy). When > customers can no longer say "gee, we collected all this information, and > who knew our web server wouldn't keep it from being published on the > NYTimes classified pages?", then vendors will be compelled to deliver > pieces of the solution that allow THE CUSTOMER (product consumer) to > secure their environments. > > Get ready. Trusted Third Party evaluations, like FIPS 140 is for > Crypto, will be the thing insurance companies look to for guidance in > factoring their risk exposure when asked to provide warranty coverage to > businesses using technology - just like they did to Underwriters > Laboratories for electrical appliances, just like they do to D&B for > commercial credit processing, just like they do to MasterCard and VISA > for consumer credit processing. > > And before you say "well, that doesn't apply to internal company > security", ask yourself how many companies outsource physical security > to Brinks or some other security-guard employeement agency. They can do > that, too, because of other insurance (personal bonds) that help them > lay off the exposure to misplaced trust. > > Trust is heavily outsourced. Only the very large or very foolish think > they can "go it alone". And the very large generally have governments > in their pockets to help provide the stop-loss limits for their > exposure. > > No? We are looking at the same word and seeing a very different meaning :) iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]