Folks;
There really seem to be two different goals that are trying to be satisfied with
this one mechanism. The first is a casual / quasi casual method to 'hide' a
communications between 2 parties without involving big complicated and costly
procedures and organizations. The second is to maintain all of the laudable
characteristics of privacy, integrity, and authenticity in a more relaxed manner.
The danger in the this discussion is the blending of one method and assuming the
other goal.
Observation-- There are only a handful of formally valid selfsigned certs. These are
the root CA certs. And it seems that there are myriad problems remaining in the
implementation of procedures to handle all of the 'icky' problems like validity,
expiration, and compromise of the root certs. Are all of those problems inherent with
the 'gen-a-cert' proposals? Are the solutions the same.
Observation-- Social engineering a user to add / replace a root cert seems relatively
easy. Since they aren't, in general, understood; distributing one with a single extra
space in the DN (displayed with a proportional font) looks exactly the same. With
hundreds of self-signed certs in a browser's cache, will this be easier or harder?
And remember, any tricks like omitting the CA bit doesn't stop someone from using
OpenSSL to create a cert that looks more like the real CA root certs.
Observation-- Validation has not proven to be a realizable task. While the RFCs talk
of methods and archives and perfect comms; it just hasn't happened. We don't really
know if this whole thing is scalable to 50 million users or not. I suspect it is not.
Maybe after 5 years or so where we have gone through all of these scenarios in the
real world can we tell.
Observation-- The keys are in the hands of the interface implementors! The browsers
and the CA's, and the OCSP servers. When a browser displays 'invalid cert' because it
can't follow the chain (or it is selfsigned and not on the list) it is telling the
user that they (the user) can't use the real info and that a judgment has been made
in their behalf. I want to see that cert. *Every field*. Why is it invalid? What was
it supposed to do? Who faked it? .....
Observation-- User(client) education is really needed, but so is user(server)
education. Most certs presented from servers are either expired or the DN doesn't
match the DNS name, or selfsigned. Why? What does this tell a general user? Along
with any ANS.1 display should be a button 'explain?'. This says:
"This cert is self signed. No one vouches for its correctness,
uniqueness, or accuracy. It satisfies requirements for encryption
but not authenticity of the remote party... Caveat Emptor!!"
Messages need to be meaningful to the people reading them. "Fails to meet section
3.4.2 of RFC 3478" is precise and exact, but not very helpful.
Well enough, I have been following this group for a while and just had to drop in.
Rip Toren
Stuart Ballard wrote:
>
> Michael Str�der wrote:
> >
> > > Are you (and Ben) seriously suggesting that an encrypted message sent to
> > > a self-signed key belonging to even a naive user is *no more secure*
> > > than a plaintext email?
> >
> > I think the point that Ronald and Ben addressed was that if the user
> > gets flooded by self-signed certificates it will not be possible to
> > make him validate a certificate properly later at all. It's just a
> > matter of humans getting used to bad habits. One has to consider
> > this when designing a UI.
>
> So all users should be stuck with plaintext mail until someone can teach
> them Basic Cryptography? It still seems to me that if the choice is
> between users with encrypted mail but bad security habits, and users
> without encrypted mail at all, I'll take the first option.
>
> Most users don't know how to pick good passwords either, but that
> doesn't mean that ISPs should use password-free email accounts until the
> users can be educated.
>
> Stuart.
