Trust is Ambiguous
Recently, I've been working on a problem similar to the following: a client accepts a digital certificate associated with a piece of remote code (ActiveX, Java Applet, etc.) The code signed using the certificate might be designed to do something benign like download weather information to the client's web browser. Sounds harmless. But what if a malicious party takes the remote code, leaves it intact, serves it to a client who has accepted the certificate, and then tricks the remote code to download to the client's system something other than weather information - say, spambot software? This produces an outcome far different from what the user had in mind when they accepted the digital certificate to view their local weather.
The problem here is that digital certificates are rarely restricted to a specific operation. The client can't say "Yes, I trust company XYZ, but only to download weather info." Rather, they can only say "I trust company XYZ." In this sense, the trust relationship is very ambiguous. As an analogy, I trust my auto mechanic to work on my car, but I don't trust him to prepare my taxes.
Computing applications, particularly those that are networked, need a more precise method of defining and restricting trust. The consequences of not doing so can lead to horrible surprises for software vendors and customers as they begin to see their trust relationships exploited by people with malicious intentions.