Date: Fri, 25 Mar 94 15:08:28 EST
From: jueneman%wotan(_at_)gte(_dot_)com
...
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)?
Dead drops already exist on the Internet. Most usenet newsgroups can
qualify (and a group of people can create one just for this
purpose). There are also things called Cypherpunks remailers. These
permit one to send an anonymous message which is routed via a set of
independent (from each other) mail transport agents. By clever use of
encryption each remailer only has knowlege of the immediate previous hop
and the immediate next hop in the chain.
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.
Although I am not a lawyer, I don't believe that you have any civil liability
when you turn over business records to a law enforcement authority that has
produced appropriate legal requests (i.e., subpoenas).
On a practical basis, the RSA Persona responder is a single point of failure
and delay. Using RIPEM, I can generate a key pair *now* and immediately use
it to talk to people on the MIT campus, even if my external internet connection
is down (not to mention RSA's connection).
I would like to include PKCS and other formats in that list as well, but I
agree.
Agree, not mentioning PKCS was an oversight on my part.
I think my suggestions regarding implementation-dependent key caching
accomplishes this, and doesn't necessarily require an RFC. Do you agree?
No, I do not agree. RFC1422 makes specific requirements about DN subordination
in an attempt to enforce a strict hierarchy. One can write a PEM like program
(aka RIPEM) that doesn't meet this requirement. However it is then not
meeting the requirements as defined by the RFC!
Btw. I believe that if we permit looser trust models then RFC1422, we should
do so in such a fashion that makes it clear to an end-user which trust
model is in use. In other words, I believe that there is value in the
RFC1422 approach and we should make sure that implementations that support
non-1422 style authentication clearly indicate when a signature is verified,
whether or not 1422 (or any other trust model) is in use.
I want to add value to the PEM effort, not destroy the work that has been
done.
>proposals that require less infrastructure
Yeah, maybe. God is in the details, and I haven't seen just how this would
work.
Take a look at PGP and RIPEM. They work and do what their constituencies
desire.
-Jeff