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

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

> 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 :)


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to