James and Aram, thanks for your comments. My reply is inlined

James A. Donald wrote:

X.509 / PKI (Public-Key Infrastructure), PGP (Pretty Good Privacy) and IBE (Identity-Based Encryption) promise privacy and security for email. But comparing these systems has been like comparing apples with speedboats and wingbats. A speedboat is a bad apple, and so on.

We can, and should, compare any system with the attacks that are made upon it. As a boat should resist every probable storm,

Boats are storm rated, however. The point here is how can we
"storm rate" secure email systems?

For example, it might be a good idea to have different tables for
attacks vs. problems (for boats: resisting pirates versus
resisting high waves). For example P13 (must pre-enroll recipients) may
be a problem and it really is something different compared to an
attack, i.e., a problem leading to an attack such as P12 (open message

However, in order to make some progress in this, I felt a need to
simplify things into + and -. This makes sense also in terms of
attacks vs problems (for email, maybe not for boats!) because a
secure email system that has a lot of problems will likely be used
badly (insecurely) or not at all -- which opens room for attacks.
So, both problems and attacks are negative for security.

What I'm saying is that we can, and do in many other cases,
compare different systems in terms of their features and
shortcomings. Irrespectively of how we may further classify them,
a feature is + and a shortcoming is -. For example, that's how your
car value is estimated when you sell it -- by how many negative and
positive points it gets. It doesn't matter if the negative points
came from a dent or an absence of air bags, they all count negatively.
I'm looking into each product individually and building a collective
metric based on technologically-neutral specifications for + and -.
To do this, the paper asks two questions:

(1) what are the product's capabilities in terms of a list of desired
features (the +), and

(2) what are the product's shortcomings in terms of a list of attack/
problems (the -),

for each main market product using those technologies and assigns each
score (+ or -) to the technology used by that product. At the end
of this algorithm, scanning enough products, we have a list of all
capabilities and all shortcomings that affect each technology.

Of course, each feature and problem/attack is intended as optional --
you can pick and choose what you want from the list, to make your
own subset of the score card, valid for your needs (and amount of
money you want to pay).

These lists are an intrinsic "yardstick" that we can use to both rate each
technology and also, if we want, each individual product. For example, a
product that has 80% of the positive score and 20% of the negative score
for that technology is possibly better than a product using the same
technology that would have 20% of the positive and 80% of the negative
for that technology. We can, in the same way, compare products using
different technologies, comparing their score cards.

Problem 1: The primary weakness of existent email is its vulnerability to after the fact investigations.

For example P1: giving others the ability to get your private
key at a server without your knowledge or consent.

Anything we can do to negate "after the fact investigations" is
useful , such as protecting the email headers (communication
security, not just message security). The paper's score card
reflects several aspects of this, in its positive and
negative scores.

Problem 2: The secondary weakness is ease of forgery.

For example P1 to P8.

Crap with certificate authorities or web of trust just is not flying, and is not going to fly.

Depends on your use. An X.509 identity cert or a PGP cert
can be made as secure as you wish to pay for. The real
question, however, that is addressed by the paper is
how useful are they in terms of email security? How do
you compare them and which one or which product to choose
from? What are the trade-offs?

 To limit the number of
possible copies, email should be sent by a direct
connection from the client to the recipient mail server,
rather than this store and forward crap.

Store and forward makes it reliable -- nothing needs to be
100% online 100% of the time (which is, of course, a totally
improbable event).

Ed Gerck

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

Reply via email to