On 30 Dec 1997, EKR wrote:
-> 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.
I disagree, because the security holes mentioned are perfectly allowed by
the S/MIME standard. So, such implementations are 100% S/MIME-compliant
-- which they should never be if the standard would aim at a higher
security level.
->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.)
I must again disagree. It is a common misconception that a third-party
manufactured hardware token would magically infuse trust into the final
result of a cryptographic calculation. As we know, trapdoors can be easily
inserted into the calculation of keys or signatures, arguably more
stealthly in a hardware token with concealed and secret source code.
->
-> > 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.
->
The issue here is not syntax but semantics. Clearly, a root key does not
exist by itself -- it is issued by someone, which is where the bucket
stops.
It is immaterial if this someone cryptographically signs the public
root-key (to provide for origin and data authentication in an open
environment) or seals it unsigned in a tamper-proof secure token that
provides for origin and data authentication by itself, or "seals" it using
any other method (such as encryption), or etc. In any case, the issuer is
"signing" the root-key (signing as with a seal) -- either in software, in
hardware, etc. The main point here is that the issuer is adding the same
semantics in any such cases: "This public-key was issued by myself
according to my policy A and its private counterpart is further kept
according to my policy B" -- which you cannot prove or otherwise test for
A or B but must trust if you desire to accept it.
There is no way a root key can exist by itself as an absolute reference --
which makes self-signed (signed in the semantic sense) certs unavoidable
when using extrinsic certificates, which is another you can read my phrase
above.
Cheers,
Ed
______________________________________________________________________
Dr.rer.nat. E. Gerck
egerck(_at_)laser(_dot_)cps(_dot_)softex(_dot_)br
http://novaware.cps.softex.br