Lars Eilebrecht wrote:
Lars,
Thanks for your nice words.
In order to make some progress on this, I felt a need to
simplify things into + and -. This makes sense also in
terms of attacks vs problems because a 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.
[See also my previous reply on this to the posting by James Donald,
in this blog]
That's why I had "X.509 / PKI" -- even though PGP's
WOT doesn't qualify as a PKI (no central management).
They are also fundamentally different in other aspects.
I've summarized this in http://nma.com/papers/certover.pdf
The different technologies are compared in terms of the
market products they support. It's a capability (and lack of
capability) analysis.
The message format (and the application) reflect what
the technology needs and can provide support for. S/MIME
is not the same as PGP/MIME, in the same way that the old
PEM was also different (and there's also PGP without PGP/MIME).
I'm looking into each product individually and building a collective
metric based on technologically-neutral specifications for + and -.
[See also my previous reply on this to the posting by James Donald,
in this blog]
This is not so relevant for the analysis.
For example, both X.509 and IBE (suppose) support S/MIME.
However, that doesn't make them equal in terms of their
features (the + in the score cards). You can revoke a X.509 key
and have S/MIME tell you that for X.509 (score a + there)
while you can't revoke an IBE key (doesn't score the +).
However, you could expire both X.509 and IBE keys (even
though Voltage does not say it for their product, it's in
their IBE papers) and, therefore, both score a + there.
Key revocation is expressed in S/MIME differently than in
PGP/MIME, though. In general, a technology's limitation
(for example, no central key revocation in PGP) will
reflect itself in the encoding used and in the product,
which is what is measured to create the score card.
If you're familiar with that product, I'd like to add their
scores to the respective technology column.
Regards,
Ed Gerck
According to Ed:To help develop a common yardstick, I would like feedback (also by
private email) on a list of desirable secure email features as well
as a list of attacks or problems, with a corresponding score card for
the secure email technologies X.509 / PKI, PGP and IBE. The paper
is at http://email-security.net/papers/pki-pgp-ibe.htm
Nice paper. I don't had time to look at it in detail, but here a
few minor comments ...
Lars,
Thanks for your nice words.
I think it would be better to have different tables for
attacks vs. problems. For example "must pre-enroll rcpts" may
be an "unwanted feature", but it really something different
compared to an attack, i.e., a problem leading to an attacks
such as "open message headers".
In order to make some progress on this, I felt a need to
simplify things into + and -. This makes sense also in
terms of attacks vs problems because a 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.
[See also my previous reply on this to the posting by James Donald,
in this blog]
Further, I'm not sure about the general categories you have.
"PKI" is a very broad term. PGP and it's web-of-trust is
also some kind of PKI and of course I could build a closed/private
PKI using OpenPGP keys.
That's why I had "X.509 / PKI" -- even though PGP's
WOT doesn't qualify as a PKI (no central management).
They are also fundamentally different in other aspects.
I've summarized this in http://nma.com/papers/certover.pdf
It may be easier to compare the different technologies if
you compare the message format (e.g., S/MIME vs. PGP/MIME)
independent from the rest of the system, i.e., from the PKI.
The different technologies are compared in terms of the
market products they support. It's a capability (and lack of
capability) analysis.
The message format (and the application) reflect what
the technology needs and can provide support for. S/MIME
is not the same as PGP/MIME, in the same way that the old
PEM was also different (and there's also PGP without PGP/MIME).
As "PKI technologies" I would think of X.509-based PKIs (PKIX),
vs. IBE-based vs. OpenPGP-based ...
An attack against "open message headers" is not related to
a system using X.509 certs or OpenPGP keys, but it just
a matter of the message format being used, e.g., S/MIME.
I'm looking into each product individually and building a collective
metric based on technologically-neutral specifications for + and -.
[See also my previous reply on this to the posting by James Donald,
in this blog]
If I remember correctly most IBE-based system also use
S/MIME or at least something derived from it like the Voltage
IBE product.
This is not so relevant for the analysis.
For example, both X.509 and IBE (suppose) support S/MIME.
However, that doesn't make them equal in terms of their
features (the + in the score cards). You can revoke a X.509 key
and have S/MIME tell you that for X.509 (score a + there)
while you can't revoke an IBE key (doesn't score the +).
However, you could expire both X.509 and IBE keys (even
though Voltage does not say it for their product, it's in
their IBE papers) and, therefore, both score a + there.
And an attack related to how key revocation is handled is
unrelated to a system using S/MIME or PGP/MIME.
Key revocation is expressed in S/MIME differently than in
PGP/MIME, though. In general, a technology's limitation
(for example, no central key revocation in PGP) will
reflect itself in the encoding used and in the product,
which is what is measured to create the score card.
BTW, have you considered adding the Ciphire system to your
comparison (http://www.ciphire.com)?
If you're familiar with that product, I'd like to add their
scores to the respective technology column.
Regards,
Ed Gerck
No comments:
Post a Comment