On Thu, 23 Feb 1995 Jueneman(_at_)gte(_dot_)com wrote:
DES can no longer be considered strong enough to protect important data. Is
128-bit IDEA stronger than 56-bit DES? Who knows? I'd like to see PEM adopt
triple-DES and be done with it.
I'd like to see PEM adopt triple-DES as well, but I wouldn't rule out IDEA
as casually as you have done. It is not our place to decide what may or may
not be secure in the future. If we support a range of options, then users
are protected when one fails because they can simply disable the insecure
algorithm and use what remains. We already support both RSA and DSA in PEM.
DSA is fairly new and some have grave reservations about its security.
The original version of DSA came under heavy criticism because of its use
of a common modulus. Who says that the current version is any better?
This working group is not in a position to decide.
Where PGP falls down, at least in the current version, is that the mechanisms
for certificate revocation are rudimentary. Certificates don't have expiration
dates,
Expiration dates don't add anything to the security of PEM over PGP. If
anything, the only use I've found for them is to force users to have to
pay again next year to get their certificate re-issused. PGP doesn't
include such restrictions on what people can do with their own keys.
Who is right and who is wrong? It doesn't matter. They are merely
different policies.
and there is no requirement that users check a repository to see if a
certificate has been revoked. (Of course PEM's implementation of CRL's,
especially the distribution of them, isn't something to brag about too much
either.)
I hate the word "requirement". Getting or not getting a CRL is a policy
matter. As Amanda has pointed out in the past, policy is not something
that you write into computer programs. If I want to honour a certificate
without having a CRL, that's my business. If I get burnt for it, it is
my fault.
In addition, there are no constraints other than an individual's judgement as
to what kind of identification should be required before signing someone's
key,
and there are no contractual or other kind of binding agreement between a
certifier and a user. As a result, it would be very difficult to sue a
certifier, even for gross negligance.
Except for mis-certification, I think it would be incredibly stupid if
certifiers could be sued. This comes back to the responsibility question
on the Internet: should providers be responsible for what their users say
and do? Should certifiers be responsible if someone commits fraud with a
certificate that was issued by them? If so, we'll have very few CA's
willing to certify anything. By default, the binding should be limited
to "We have checked this person's identity according to policy X and we
allow them to perform transactions of type Y. Any responsibility for
said transactions rests solely on their shoulders".
Aside: I never will understand the American propensity for "we must find a
way that we can sue them if something goes wrong". Maybe you should all take
a crash course in what is known in Australia as "Alternative Dispute
Resolution", involving non-legal means of solving problems. It saves a
heck of a lot of money and heartache.
L:ikewise, when a user generates his certificate, he is free to include almost
anything he likes as a "name" field. There is not necessarily any tie to the
user's organization, and it is somewhat unlikely that individual certifiers
would actually check to see if a person's residential address is correct.
So what? If a name is not signed by the correct entity that is supposed to
sign that kind of name, the certificate or PGP key block will be rejected.
It should not matter if I can put an arbitrary name in my certificate. What
should matter is "Can it be checked?". I'm sure I could whip up a certificate
in 30 seconds flat that would look and smell like a Mastercard certificate.
I may even sign it with some fake CA key that I made up to make it look even
more legit. But, when I send that to someone else, they immediately know
that it is a fake. Unless of course I've managed to corrupt the other
person's key database as well. But if that happens, there are bigger problems
afoot than a user choosing an incorrect name.
I firmly believe that residential addresses should not be included in
certificates that are used for Internet e-mail. They may be useful for
government-issued smart cards for health care and what-not. But for
Internet e-mail they are unnecessary baggage, and a threat to privacy.
The e-mail address is sufficient to identify an Internet e-mail user who
is not affiliated with an organisation. To head off your "but you cannot
verify it" response, I point out that quite some time ago I proposed a
CA hierarchy based on the Internet domain name system using the current
DNS administrators to take care of name validation.
I think the real differentiation will come when PEM adopts X.509 v3, for that
will allow all fo the policy issues to be spelled out and enforced much more
easily and efficiently. Of course, if the PGP community wanted to, they copuld
adopt X.509 v3 (or their own alternative) as well, in PGP version 3.0.
I suspect that they will instead develop their own mechanisms to deal with
these problems. X.509v3 has no monopoly on "good features" and PGP's
feature set is not set in concrete.
Cheers,
Rhys.
--
Rhys Weatherley, Queensland University of Technology, Brisbane, Australia.
E-mail: rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au "net.maturity is knowing
when NOT to followup"