On Mon, 29 Dec 1997, David Sternlight wrote:
David:
I have enjoyed the postings and the replies on the thread you initiated on
the subject above. The fact that you cited my paper (Overview of
Certification Systems) may have helped ;-)
However, I have five comments.
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.).
2. What is the goal of S/MIME? S/MIME wants to be a simple no-liability
(i.e., to the companies involved, as has been clearly spelled out in this
thread) system that can provide for "secure" e-mail messages as the
average user may need them, where "secure" means whatever you care to
understand by that word. How good is a S/MIME signature in an e-mail
message if your private-key may have already been compromised when it was
generated, or snatched at a later time? As has been often said, you get as
much as you paid for it (browsers and its S/MIME MUAs are essentially
free, as we all know) and different vendors may offer more bells and
whistles.
3. *All* certificate chains eventually end in a self-signed cert. So,
self-signed certs MUST be acceptable by S/MIME and the text you quoted
MUST NOT be dropped otherwise you would just need to introduce yet another
way to accept a self-signed root certificate -- which would defeat the
purpose of prohibiting it. It's the CA paradox -- "trust me because you
have no other choice". So, by further induction, there is no sense in
S/MIME for banning other self-signed certs just because they did not come
from a CA.
{The true and (provable) only solution to this Catch 22 situation is to
use intrinsic certificates (that can be used by themselves or to bootstrap
conventional extrinsic certificates such as a CA's). This is referenced in
http://mcg.org.br/intrinsic.htm}
4. With the current model, then, S/MIME may indeed coherently accept
self-signed certs because the deployed trust model is already local --
i.e., either the CA is trusted by you or it can be trusted if it is
trusted by a CA you trust, you know who self-signed the cert, etc. In
other words, this builds up a local trust domain, which is perfectly valid
for users in its domain (whereas being a leap of faith on a global level,
but that is besides the point)
5. Within such a parochial model, a further increase in the security level
can only be achieved with insurance -- such as already being sold by
VeriSign for S/MIME certs, which has the added benefit of providing for a
secondary market (and a tertiary market for lawyers specialized in
international liability, consulting and litigation) without decreasing the
first.
Cheers,
Ed
-> One reader sent me an e-mail indicating that he didn't see what my original
-> post had to do with the deliberations of this group. Here is a copy of the
-> clarifying response I sent him:
->
-> My objection is based on the current quote from draft-ietf-smime-cert:
->
-> "Clients MAY send CA certificates, that is, certificates that are self-
-> signed and can be considered the "root" of other chains. Note that
-> receiving agents SHOULD NOT simply trust any self-signed certificates
-> as valid CAs, but SHOULD use some other mechanism to determine if this
-> is a CA that should be trusted."
->
-> The provision of self-signed CA certificates corrupts the rigid heirarchical
-> model, and I think the hand-waving "should use some other mechanism" casts
the
-> huge body of arms-length users unable or unwilling to check such a CA's bona
-> fides adrift. It can ruin the "bank check/credit card" model of S/MIME as
-> practiced in Netscape and Explorer via Verisign and the many other
certifiers,
-> where CAs are required to conform to specified standards, and are audited to
-> that, just as banks are supervised by the Controller of the Currency, and
-> credit card issuers by VISA, MASTER CARD, etc. While I have no objection to
-> web of trust as a separate model in some other standard, to weaken S/MIME in
-> this way can destroy its usefulness as a routinely trusted medium (just
-> as are VISA and MASTER CARDS and checks after perhaps checking only the
-> individual account's validity--corresponding to a user's public key).
->
-> I speak as a professional economist. For details, read any good introductory
-> economics text on money and banking. The conceptual issues are exactly the
-> same for trust here (whether for e-mail or transactions) as they were in the
-> abolition of specie money and the rise of national banking systems, and
-> subsequently national and international credit card systems.
->
-> My recommendation is that the subject paragraph, and any other opening for
-> self-signed CA certificates be dropped from the standard.
->
-> David
->
______________________________________________________________________
Dr.rer.nat. E. Gerck
egerck(_at_)laser(_dot_)cps(_dot_)softex(_dot_)br
http://novaware.cps.softex.br