At 05:00 PM 1/11/00 , [EMAIL PROTECTED] wrote:
>For the CA-based trust infrastructure to work for this scenerio ... the CA
>needs
>to be asserting the trust/quality/integrity of applications produced by each
>software company (so that I only need to record CA-level trust decisions) ...
>once I need to record vendor-level trust decisions then I've truncated any
>trust
>hierachy (embodied by a CA which then becomes superfulous/redundant).
While this would certainly be an interesting goal to achieve, I think it's
worth remembering that current software industry practice is for the
software publishers themselves to disclaim all or almost all warranties
regarding the performance of their software or its lack of errors .. so
you're asking CA's to guarantee something that publishers themselves don't,
at present.
Further, CA's (well, the cautious ones) carefully limit their liability to
third parties who rely on their statements - the customer of a CA is likely
to be different from the end user who wants or needs to rely on the CA's
assertion.
The above model would change both of the above practices - putting the CA
on the hook to the end user, and making a positive warranty about one or
more aspects of the software's performance.
At present, the risk ( = cost) of software failure rests on the
purchaser/licensee, who's frequently unable to measure or calculate or
otherwise account for it, so it's mostly ignored. Shifting that cost to the
publisher/licensor or a CA or their insurers means that the cost will be
measured and calculated and not ignored. Because end users mostly don't
account for that cost, they're not likely to assign a high value to a
transaction which shifts that cost to another party; but the party to whom
the cost is shifted will want to value the transaction at its cost, or
higher, because the cost can't and won't be ignored. The difference in
apparent value of that cost-shifting transaction makes it unattractive to
one or the other of its participants.
Thus, while the scenario you describe is an attractive one (especially if
I've got my end-user hat on), I suspect that it's unlikely to see the light
of day any time soon.
--
Greg Broiles
[EMAIL PROTECTED]
PGP: 0x26E4488C
