1. Using DNs as the primary search key to certificates, but using [...]
2. As a number of people have pointed out, DNs are cumbersome. They [...]
3. As a result of #1 and #2, PEM is HARD TO USE. While we all may be [...]
4. One problem which I'm surprised hasn't come up that much before is [...]
5. The chicken and egg problem of having to get certificates signed before
they can be used. e.g.
User: I would like to use PEM in my e-mail.
Admin: OK, get this software, generate a key, find someone to sign your
key, and off you go.
User: Who do I get to sign my key?
Admin: No idea.
User: So what use is PEM!?!
Admin: Complain to pem-dev(_at_)tis(_dot_)com(_dot_) I didn't design it
this way.
Compare this to:
User: I would like to use PEM in my e-mail.
Admin: OK, get this software, generate a key, and off you go. If you would
like greater authentication on the net as to who you are, then you
can get your key signed by someone else.
User: Fine, so who would I get to sign my key if I wanted to do that?
Admin: No idea, but if enough users at this site start using PEM, then
I will consider setting up a CA to sign the keys. But, if it is
just you, I don't see much need to do this. OK?
User: OK.
For me, this is a very pressing problem with PEM. PEM will only take off when
it is easy to start using it and then add extra authentication layers on a
per-user basis when it is needed. This can be done with RIPEM now, through
a hack, and it amuses me no end to see some people on this list signing
their messages with RIPEM rather than a real RFC-compliant version of PEM.
Is it just the e-mail naming problem that is causing people to use RIPEM,
or is it also the "use now, sign later" model that RIPEM supports, but
"pure" PEM doesn't? (Or is it that RIPEM is freely available, but the
"pure" PEM implementations aren't?) There are some hacks, like self-signed
certificates, that could be used to do this, but until I see it in black
and white in an Internet Draft or an RFC, I'll be very hesitant to use
such a hack.
There is nothing wrong with top-down hierarchies, but a method for doing
bottom-up certification would be a big boon, especially out in the
public-access boondocks where the net is growing at an alarming rate,
but without the traditional power structures that top-down hierarchies
need to work properly. In many cases, it is the boondocks that require
privacy in e-mail more than the mainstream, because it is unwise to
trust the admins along the path from the boondocks to the mainstream
to not read e-mail. These people are currently cut off from PEM because
of the difficulty of getting their keys signed, when there is no
technical reason why they just can't generate a key and talk. Hence, PGP
gets even more converts.
So, either formalise RIPEM, or re-work the CA hierarchy to allow PEM
to grow from the first adopters (users) to the power structures (admins).
(As well as re-working it to allow e-mail addresses along the way).
The current top-down hierarchy can stay: it is useful for when legal
or commercial authentication is paramount, but for casual communication,
it is a bottle-neck.
Cheers,
Rhys.