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.
You misread me. I didn't say that IDEA wasn't any good, I said that I didn't
know, and that as far as I know no one really knows, because it hasn't been
analyzed sufficiently by the half-dozen people or so in the world that could
reaonsably be considered competent to do so (and who would be allowed to
publish their findings.)
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.
Au contrare. A relatively short cryptoperiod adds to the security of a
cryptosystem by limiting the amount of damage that may occur if a key is
compromised. And if you are operating a CA, you are perfectly at liberty to
charge or not charge, and/or to set the expiration date as far into the future
as you see fit, subject to any policy established by the PCA which certified
you.
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.
You are certainly free to use PGP, or for that matter to disable some of the
precautions that have been written into PEM in order to protect those users who
might not be quite as savvy as you are. Whether you like it or not, PEM was
designed to provide a comprehensive framework for security, and included a
reasonably well thought out set of design goals, nominally including the
enforcement of certain policies.Of course, implementations may provide
overrides of the type you mentioned, perhaps with warning messages. PGP chose a
different set of design goals. A a knowledgable user I could be happy with
either. The market will eventually decide.
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".
I agree. All that I was talking about was misrepresentation of a user's
identity. We haven't discussed authorization certificates. CAs, even
deep-pocket licensed CAs, will certainly not be responsible for the acts of the
people whose identities they certify. Notaries, especially the latin style
civil notaries, may in fact accept responsibility for the content of a document
after a due diligence investigation, just a bond lawyers in the US issue
opinions as to the marketability of a bond -- without which the bond is
essentially unmarketable. Civil notaries might also be CAs, but there are two
different functions involved in issuing a certificate vs. attesting to the
legality of a document, the capacity of the signer, etc.
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.
Let's not start culture bashing. Debating the various legal systems in the
world on this list would be a rather silly exercise, rather like two blind men
debating the beauty of the sunrise.
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.
Again, I tend to agree with you in the case of e-mail. However, although PEM
was certainly oriented toward the use of e-mail, I believe that there was an
expectation that a common public key infrastructure would emerge that would
also be interoperable with other systems. Unfortuantely, we've wasted a LOT of
time arguing over the issue of naming in certificates, primarily because of the
limitations of the older certificates. If all that you want to do is protect
farily casual correspondence over the Internet, then e-mail names are fine,
whether used in PEM or PGP, and I agree that the residential person construct
buys you relatively little. However, if someone wants to conduct electronic
_commerce_ over the Internet, and many, many people want to, then your views on
the subject are rather immaterial , as it will be the banks and the merchants
that will decide what kind of identification policies, etc., they will require.
PEM is designed to provide at least some level of support for such
requirements. PGP at present is less well suited to that level of assurance,
IMHO, but that could easily change.
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.
Didn't I just say that?
Cheers,
Rhys.
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820