"Donald E. Eastlake 3rd (Beast)" <dee at SKIDROW.TAY.DEC.COM> said:
How is this any different from the Real World? When you get an order
from someone, how do you know that they aren't bankrupt or about to run
off with the goods or about to withdrawal all their money from their
bank account or, if they purport to be the agent for some business, that
they are still authorized? The answer is that you don't and there are
plenty of scams for which it is very difficult to get redress through
the legal system. Somehow the world survives.
- - -
I'm glad to see that you brought this up since it relates to an issue
that is often ignored in these security sessions. All business have
something called an accounts receivable department whose primary goal is
the prevention of just the sort of attacks that you seem to feel cannot
be defended against. They all have a communications link to some credit
reporting system. For a security system to fit within the business
community, it must support business needs and practices. Neither PEM
nor PGP has ever included, as a design goal, support for these types of
activities. As electronic commerce starts to grow, those communities
have chosen to develop their own security protocols. As a practical
point, that seems to be an indictment of both email security protocols
as insufficient for business communications. Snail mail has found ways
to support business communications, and only survives because of the
huge volume of business mail.
But we digress, the question was whether secure communications were
required to support certificates. My point is solely that without
secure communications, the party that is seeking to acquire trust cannot
do it with PEM and CRLs unless that party can be assured that no CRL has
been issued prior to the issuing of the message. Now you can argue
sufficiency, or diminishing returns, or any other value argument that
you wish, but to be absolutely sure that the certificate was valid at
the time when the message was signed, requires a secure communications
protocol. Note that this does not need to be an encryption protocol,
but it must be secure from alteration, spoofing and denial of service
attacks.
Peace ..Tom