"Nelson B. Bolyard" wrote:
>
> 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.
This is good.
> > [ 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.
Hm. This is where you're losing me (my approval, not my understanding).
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.
On the receiving end, *trusting* such a certificate means believing that
the big company did due diligence in ensuring that the person it granted
the certificate to was really you. But either the process of getting a
certificate is even more intrusive than I thought (involving some form
of checking against real-life records that a private company shouldn't
even have access to, or physically taking my passport or drivers license
to a BigCo office before they'd issue the certificate) or it didn't (in
which case why am I supposed to trust it?).
> > [x] Automatically harvest public keys from incoming email
>
> This feature is permanently enabled in Communicator.
Cool :)
> 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.
I'd like to see them turned on by default, but I grant that having them
is very good.
> This feature is permanently enabled in Communicator.
Again good.
> 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.
> 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.
> > 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.
It depends on whether the user is aware of where the holes are, and
whether the security that really is provided is still worthwhile. See
below for an analogy.
> 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.
Granted, to a limited extent, but see above for what I think about the
"certifications".
> 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.
True, but *both* types of users can benefit from crypto. I believe the
PGP model includes an infrastructure for a sort of "collective"
certification of keys, but (obviously) I was totally ignoring even that
level of security, and I'm *still* claiming that the result is
worthwhile.
Consider ssh, where you are connecting to a remote system over an
encrypted channel. For your first-time connection, you have to trust
that TCP/IP is going to get you to the right host, your connection isn't
being spoofed etc. After the first connection though, you are secure
(because the server's key signature is cached locally). Your reasoning
would suggest that ssh is only "false" security because the initial key
exchange isn't done over a trusted channel. But I (and presumably all
the other millions of ssh users) consider that the security ssh provides
is still very much worthwhile and that the small window for MitM attacks
is not a reason to give up the very real advantages of encrypted
connections and assurance that every subsequent connection is legit.
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.
In practice, even this one hole can be reduced if not eliminated (to the
extent that most non-business users and some business users need) by
simply putting a suggestion in the UI for sending the public key along
the lines of:
"You should include, if possible, some information that the recipient
will be able to identify as coming from you, such as an in-joke or a
reference to a recent conversation."
The harvesting process can do the same thing in reverse:
"This mail contains a public key that claims to be for XXX. You should
not trust this public key unless there is information in the email to
prove that it is really from XXX. Alternatively, contact XXX by some
other means and confirm that he/she really sent this message."
> > 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)
I meant "raise the bar for the people implementing the UIs" :)
Which lowers it for everyone else...
> 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.
Or coming up with a system that lets people get most of the benefits
without requiring certs.
Stuart.
