Frank Hecker wrote:
>
> 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.
This is more-or-less my point; I'm just emphasising that although
Netscape (4.x at least) has historically been good at supporting the
corporate users, it's historically been much worse at offering secure
mail to the non-corporate users, where PGP or your suggestion below are
more appropriate.
> 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.
Yep!
> 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.
Thanks for the explanation - I didn't realize that it was done that way.
> 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.)
Yes; my point was that you *could* use a similar mechanism to store
encrypted messages being sent - to use your terms, generate a symmetric
key (or use the same one from the passwords) and use it to encrypt the
mails on disk. I do see why it wasn't done this way though - my way
would have issues if multiple clients are using the same mbox.
[snip information about client authentication - interesting but not (I
don't think) directly relevant here]
> 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.
I wasn't really suggesting a new protocol as such, just a UI that
facilitates using them in the mode I described (and you describe below
in more detail for S/MIME).
> 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.
Yes, that would be one good solution (especially if it was prominently
visible in the UI, and the relevant prefs were all turned on by default,
and a self-signed certificate was generated during the
install/createprofile/migrateprofile process).
PGP support would be great too, and would provide similar advantages.
Stuart.
