Stuart Ballard wrote:
> "Nelson B. Bolyard" wrote:
<snip>
> While I appreciate that S/MIME is based on certificates, I think of that
> as a flaw in S/MIME, not a benefit. As you know, getting a certificate
> means giving all your information (and some money? I know it costs money
> for a secure website) to some big company that personally I don't
> particularly trust at all.
S/MIME is popular in corporations, and corporations can issue
certificates for their own employees at minimal or no cost per employee.
Corporations also already have lots of information about their employees
and a pre-existing relationship with them.
My take on the S/MIME vs. PGP debate is that as conceived and deployed
in practice S/MIME and PGP/OpenPGP embody different ways of thinking
about secure mail and the trust issues around it, and as a result they
end up addressing different markets and different types of users and
uses. I used S/MIME secure mail extensively while at Netscape, but also
would have used PGP (for a different set of recipients) had it been
supported in Communicator as well.
I think having both S/MIME and OpenPGP support in Mozilla would be a
good thing, because Mozilla-based products will end up being used by all
sort of users in all sorts of environments. I haven't kept up with the
evolving state of secure mail protocols, but I don't think either
protocol is going away any time soon; rather they'll coexist in the
market for some time to come.
> > Part of the
> > reason why Communicator requires you to have a certificate for yourself
> > before you can send an encrypted email to someone else is so that you
> > will later be able to decrypt and read the email that has been stored
> > encrypted on your disk.
>
> PSM achieves on-disk encryption of sensitive information without needing
> a certificate, so it's not a requirement. I don't think you meant to
> suggest that it was, though.
When S/MIME is used to send encrypted message, the message contents are
encrypted using a (pseudo)randomly-generated symmetric key (e.g., for
3DES), that key is encrypted once for each recipient using the public
key of that recipient, and those encrypted copies of the key are sent
with the message; the original (non-encrypted) symmetric key is
destroyed.
If you have a copy of an S/MIME encrypted message sitting in one of your
mail folders, the only way you can read it is if you have a private key
corresponding to the public key of one of the recipients (so you can
decrypt the key needed to decrypt the message contents). That's why
Communicator requires you to have your own personal certificate before
sending an S/MIME message, so you will already have your own private key
and public key; whenever it sends an S/MIME-encrypted message it uses
your public key to create an encrypted copy of the symmetric key used to
encrypt the message contents. (This is done whether you are explicitly
listed as a recipient or not, i.e., whether or not you're on the to, cc,
or bcc list.)
> > That DB is used not only for email but
> > also for client authentication in SSL. The password used to encrypt the
> > content of that file is used as a form of "single sign-on" for SSL sites
> > that use certificate based client authentication.
>
> This sounds to be exactly what PSM in mozilla does now when I choose to
> encrypt sensitive information (for form-autofill etc). But again, it
> doesn't require a certificate to do so.
There are different authentication mechanisms involved here. For web
sites using password-based authentication over plain HTTP (or HTTP over
SSL without SSL client authentication), you can have the various
passwords encrypted on disk, with your passphrase used in generating a
symmetric key to encrypt the passwords and then decrypt them later as
needed when connecting to the sites. (I use the term "passphrase" to
distinguish this from a web site password.)
For sites using HTTP over SSL and SSL client authentication, the data
encrypted on disk (and decrypted after entering the passphrase) is a
private key associated with your personal certificate. The private key
is used in an SSL-based authentication method that essentially replaces
the use of web site passwords.
Use of SSL client authentication is very rare outside corporate
environments. Almost all secure sites on the public Internet use SSL
without SSL client authentication; the SSL protocol provides encryption
of the data traffic, but the actual authentication is done using web
site passwords just as in the case where SSL is not used.
> What I'm basically proposing is to make a BASIC form of secure email as
> ubiquitous as ssh is becoming (granted, it's taken a while for telnet to
> go away, but blame the US govt :) ). By skipping the certification step,
> we open up one small hole (but as I said, the certification idea has
> holes anyway) but so long as we don't fall down that one hole, we
> provide excellent security thereafter.
We already have two secure mail protocols in active use, PGP/OpenPGP and
S/MIME, each of which serves particular sets of users in the overall
market. So I don't think we really need a brand new secure mail protocol
per se. What you are proposing could be done in the S/MIME world by
allowing users to generate public/private key pairs and then issue
their own (self-signed) certificates to themselves. A pair of users
could then send signed S/MIME messages to each other; the signed
messages would automatically include a copy of their certificates and
thus their public keys. The users could mark each other's certificates
to be trusted for email, using whatever method they wanted to use to
ensure the other of their identity. Since the users would have each
other's certificate/public key, they could then send encrypted email to
each other. No third party would need to be involved at any point.
That's arguably a useful mode for some people to use S/MIME. It wouldn't
have PGP-style "web of trust" benefits, since users wouldn't be signing
other users' certificates, but that may not matter for some. Once
Mozilla gets its own S/MIME implementation then anyone will be free to
write code to enable this functionality and propose it for inclusion in
the mozilla.org source tree.
Frank
--
Frank Hecker work: http://www.collab.net/
[EMAIL PROTECTED] home: http://www.hecker.org/
