Stuart Ballard wrote:
> I'm thinking particularly of signed and encrypted mail. Despite two
> useful and effective standards for it (PGP and s/mime) it's never seen
> widespread use. In designing a mass-market mail program, we have the
> opportunity to change this. But we won't do so by saying "Communicator's
> UI was good enough". It wasn't: secure websites are easy and transparent
> to access, but secure mail is a closed book to most people.
I agree with you about that point. Secure email has been described as a
"stealth" feature of Communicator. But I suspect we disagree about the
reasons for this. I think the problem is that most people don't understand
the role certificates play in secure email, and that they need to get
certificates to enjoy the secure S/MIME that's already built into
Communicator (and into Outlook Express, for that matter).
> I'm not terribly knowledgeable about crypto in general, but I understand
> the basic principles. For basic secure mail, I'd like to see the
> following options available (and preferably under mail, not under
> security, simply because the security preferences are so complex)...
I disagree that it it complexity of the UI (Communicator's UI, since N6
doesn't do S/MIME yet) that causes the problems you cite. Most of the
items in your wish list below are in fact already in Communicator, and
many of them enabled permanently, or by default.
> [ Generate me a public/private keypair ]
> [ Send an email with my public key in it ]
Your message talks about public and private keys, but never about
certificates. This makes it pretty clear that you're thinking about the
PGP modem of secure email. S/MIME is based on the use of PKI, that is,
certified public keys. Generating a public/private key pair happens
automatically when enrolling for a public key certificate. There is a
"Get a Certificate" button in Communicator's UI.
> [x] Automatically harvest public keys from incoming email
This feature is permanently enabled in Communicator.
> [x] Automatically sign outgoing messages
> [x] Automatically send mail encrypted if the recipients' public keys are
> all known
These options (exactly those two checkboxes, in fact) already exist in
Communicator. They are not turned on by default, but some Certificate
Authorities (issuers) turn them on when you get a cert of your own.
> [x] Store encrypted mail encrypted on disk
This feature is permanently enabled in Communicator. 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.
> Also, the installation process should offer to generate you a
> public/private keypair (or to import one you already have). The existing
> psm-backed encryption of sensitive data on disk could be used to store
> the private key's password, or (if generating a new key) the same
> password could be used.
Again, this is the PGP way of doing things. With PKI, keypairs are generated
when certificate "enrollment" is being done. In NSS there is an encrypted
key file that holds private keys. 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.
> The idea of "Send an email with my public key in it" and "Automatically
> harvest public keys from incoming email" is to make it trivial to
> exchange public keys.
Which is why Communicator 4.x has supported those features since 4.0.
> This initial exchange may not be particularly
> secure, but it's as secure as the plaintext email that the majority of
> the world currently trusts to send stuff around in. And the requirement
> to trust one initial email is a vast improvement on having to trust
> *all* messages.
Not really. In fact, the only thing worse than no security is false
security.
The operative word you used above is "trust". Certified public keys
(a.k.a. public key certificates) is a much stronger basis for trust than
an insecure email message that claims to be from someone you know.
PGP's model may be OK for use among friends who contact each other by
means other than email. In the business world, where much correspondence
and communication takes place with people with whom you have no other
contact, a strong basis of trust that doesn't require alternative
communication channels and relationships is required.
> Okay, so I got off into a rant, but my main point is that we should be
> looking to RAISE the bar on crypto usability,
Don't you mean lower the bar? (think pole vaulting at a track meet)
> not assume that previous attempts are good enough - especially when those
> previous attempts haven't seen wide use.
Most of the things you asked for happen automatically in Communicator once
you've gotten your own cert. The "bar" is getting people to get
their own certs.
--
Nelson Bolyard http://nelson.bolyard.com/
Speaking only for myself.
