Jeff,
I think that the RSA Persona PCA supports the first (anonymity) quite well,
Actually it doesn't. In order to get a Persona certificate I have to send
mail (with a working return address) to the responder. I have no idea
who may be logging these transactions and keeping a database. Often persons
who want to send anonymous messages want them to be truly anonymous, meaning
that *no one* can track them down. The RSA Persona PCA doesn't meet this
requirement. However RIPEM and PGP both can.
Other have already comment on your examples, but I certainly accept the
requirement.
But (and this is only partially a rhetorical question), if you are so concerned
about
the loss of anonymity possibly due to to logging of the transaction by the RSA
Persona responder, how are you going to provide anonymity for the encrypted
e-mail, regardless of how it is encrypted (PEM, RIPEM, or PGP)?
On a practical basis, you would have to be pretty paranoid to think that RSA
would like to keep all those transactions, in particular because of their
potential
liability to a law suit if the FBI or local law enforcement were to subpoena
their files and you found out about it.
I would be much more worried about your own local e-mail server logging the
outgoing mail. And in that case you have a much more serious problem, as did
Oliver
North.
One way around this would be to ask the EFF to set up the e-mail equivalent
of a CIA dead-drop. You dial in to a bulletin board and post your reply to a
coded address provided by the student. Your own address is contained in the
encrypted message, or if you want to be double blind (like the priest in the
confessional), the advisor could also have a coded address, which could be
posted in the clear. (Of course, the neighborhood snoop or fink could also
do this, which is the problem with anonynmous conversations.)
A trusted e-mail forwarder could also be used, but now the messages have
to be double-encrypted, and you have to trust the mail forwarder not to
disclose the address. Someone who is being treated for paranoia probably
won't buy that!
With regard to your other points:
There are a lot of common requirements between PEM, RIPEM and PGP. There
are many areas where they can be harmonized.
I would like to include PKCS and other formats in that list as well, but I
agree.
1) The format used to exchange messages. A common MIME format for "signed"
and "enveloped" (encrypted) messages could be used by all.
Yes. Hear, hear! A common signature block would also help, together with
a common hash function. Some applications incude time of day and some other
useful functions in their signature block. PEM doesn't.
2) The need to transport keys and key artifacts (certificates) [this may
really be part of (1)].
Certificate requests is one current problem. And Sead Muftic and I would like to
see an architected solution for positive confirmation of signature and
certificate
validity by a CA, in addition to the current CRL approach which is clumsy.
In my mind the only thing needed to keep the group together as one is a
"liberalization" of what is considered acceptable. This requires removing
two current requirements that appear to exist for proposed changes to PEM.
o Permit a trust mechanism besides a hierarchy.
I think my suggestions regarding implementation-dependent key caching
accomplishes this, and doesn't necessarily require an RFC. Do you agree?
o No longer give proposals "demerits" based on how much of a change would
be required to PEM to make the proposal "fit."
I agree, and am probably notorious for having proposed such changes in the past,
but I also don't want to throw away 5 or more years of effort lightly,
just because we don't have good implementations available yet. (I'm not
faulting yours -- it was designed for the MIT environment, and we are having a
little trouble bringing it up outside of that environment.)
I believe we need to consider on their own merits proposals that use a
more liberal trust mechanism,
I agree with that, so long as we don't preclude more conservative mechanisms
that are intended for business uses.
proposals that require less infrastructure
Yeah, maybe. God is in the details, and I haven't seen just how this would work.
and proposals that move away from X.5XX compatibility.
This I think would be a very serious mistake. I am finding ever increasing
evidence
that X.500 is expected to be THE way of distributing all kinds of information.
If someone has some particular problems with X.,500, and not just an
irrational aversion to distinguished names, then we certainly ought to address
such issues. But although a number of people have had some experience, perhaps
limited, with X.500, I've heard practically no comments from anyone as to how it
worked.
It shouldn't be hard to implement X.509 in any existing X.500 directory, and
we are in the process of doing just that. I understand that at least one
large university is in the process of issuing certificates to their entire
student
body, and storing them in X.500.
Maybe we ought to at least try it before we condemn it.
Bob