Date: Thu, 24 Mar 94 09:55:23 EST
From: jueneman%wotan(_at_)gte(_dot_)com
Reply-To: "Jueneman, Robert R." <Jueneman(_at_)gte(_dot_)com>
...
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.
Here are two examples (so you know what I am talking about) of "legitimate"
uses for such an anonymous message.
1) (I raised this example a number of years ago, so some may have already
heard this): I discover a security hole in a popular operating system. I
want to report this information to the CERT. Because of the sensitive
nature of the information itself I want it to be confidentially conveyed.
However I don't want any legal consequences to fall to me (perhaps the
software vendor decides that I violated my license agreement went I
sent my note to CERT).
An encrypted only facility meets the requirements of this transaction.
Note that a digital signature is not required on the message because the
information, by its very nature, is self validating (i.e., the hole either
works or it doesn't, CERT can verify that without me having to sign the
message).
RIPEM and PGP provide this support.
2) I have a social worker who wants to provide confidential advise to
students and/or employees. Because of the sensitive nature of the
communications involved I want them to all be encrypted. Furthermore
I may want to have some "continuity" of conversation over several messages.
I can provide a communications infrastructure that hides the transport,
but I need the "privacy enhancement" technology to support this as well.
Carl Ellison's "the key is the ID" approach fits well here. RIPEM and
PGP work here to.
I remain convinced that we can solve these problems within the
existing architecture, and feel that splintering the efforts into two
working groups would be a huge mistake.
There are a lot of common requirements between PEM, RIPEM and PGP. There
are many areas where they can be harmonized.
1) The format used to exchange messages. A common MIME format for "signed"
and "enveloped" (encrypted) messages could be used by all.
2) The need to transport keys and key artifacts (certificates) [this may
really be part of (1)].
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.
o No longer give proposals "demerits" based on how much of a change would
be required to PEM to make the proposal "fit."
I believe we need to consider on their own merits proposals that use a
more liberal trust mechanism, proposals that require less infrastructure
and proposals that move away from X.5XX compatibility.
Something I would *very much like to see* is us making progress on point
(1) above. To this end I am prepared to remove from consideration my
"alternative MIME/PEM" integration document. I believe that we can make
this progress without having closure on the other issues dividing us.
One final note (sorry for the length of this message). If the PEM WG
cannot be more liberal, then another working group is clearly called for.
-Jeff