Ed Gerck <egerck(_at_)laser(_dot_)cps(_dot_)softex(_dot_)br> writes:
1. It is clear that S/MIME does not intend to be a high-security standard
(such as could be used for banking purposes, for company-critical
information exchange, etc.), when you see for example the various
documented security holes that already exist and are simply discarded (to
name a few, the potential "trojan horse" situation of S/MIME private-key
generation in MSIE, the "on-line" S/MIME private-key generation with the
CA in the same session as used in NS Communicator, the question of no user
choice in the random seed generation for S/MIME private-key generation in
either case, the S/MIME use of self-signed certs, the possibility of
traceless S/MIME private-key snatching with an ActiveX control, etc.).
AAAAH. These aren't security holes in S/MIME. They're security holes in
S/MIME implementations. S/MIME the protocol is perfectly usable in
high security situations. As always, the implementation has to
be secure. (Incidentally, all the security holes you mention with
the exception of self-signed certs are easily solved by using a
secure hardware token for one's own private keying material.)
3. *All* certificate chains eventually end in a self-signed cert.
I don't agree with this. A self-signed cert is just one (of many) ways
of carrying a root key.
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."