Ben Bucksch wrote:
>
> Right. That's what I dream of, too. Add a crypto pane to the Account
> Wizard and the Account Manager. Then, have one option group for both PGP
> and S/MIME with the options:
> o No crypto
> o Import existing cert/key
> o Generate new self-signed cert/key
> o Apply for a cert from a certificate authority
IMHO the Wizard and the Account Manager are not the right place.
X.509 certificates expire (usually after a year). The enrollment
process has to be accessible without messing around with your
account data.
> Ideally, the default in the Account Wizard would be to generate a new
> self-signed key.
Hmm, not sure about that.
> * If the default is "Generate a new key", and users don't
> care/understand, we risk that our users flood the world with their
> certificates. We'd end up with lots of certificates for a single
> user, which would have the consequence that nobody cares about the
> validity anymore, which means that security goes south again.
Absolutely true.
> Any ideas how we could avoid that, apart from an educating dialog,
> which explains the topic quickly to the user? (Such a dialog is
> not optimal, because some users don't care and for others, it's
> intrusive/annoying to have to read it.)
I completely agree.
> An alternate (non-exclusive) approach would be to have some kind of "key
> servers", similar to the PGP ones. We could use the LDAP server
> infrastructure for that (LDAP servers are not limited to big companies -
> Bigfoot runs one, too, IIRC). This would be the opposite approach -
> userA doesn't send the cert, but userB retrieves it.
Communicator 4.x already has the capability of retrieving
certificates from a LDAP server. This already works pretty well if
properly set up. The user could also send his/her certificate to the
LDAP server (basically a S/MIME message with 0 bytes message).
The main problem with LDAP servers is finding the appropriate naming
structure. Communicator added the certificate to an existing entry
by searching for the e-mail address. There might be some problems
with S/MIMEv3 certificate profile which does not mandate the e-mail
address in the certificate's subject anymore.
> If the user requests to send an encrypted mail to another user, for
> which no key is in the local database yet, we could then query the LDAP
> server for that emal-address and check, if there is an appropriate
> certificate.
Already working for S/MIME certs in Comm. 4.x. Push [lock], push
[Get Certificates...]
> Problem: What should be done, when no cert can be found? Should the user
> send unencrpted then?
Ben, did you ever work with S/MIME mails in Communicator? You will
get a warning message-window that the e-mail is unencrypted ([Yes]
[No] [Cancel]). You can't do much more in the UI in this case.
> SaveAsDraft, ask recipient for cert manually, then
> resend?
If your directory infrastructure and local cert database does not
hold the certificate and it's important to protect the message
that's the way to go.
> >In Communicator 4.x the way to do this was to
> >send the other user a signed S/MIME message. However I think that method
> >is not very intuitive
> >
> It also has the disadvantage of wasting a lot of bandwidth.
Adding the cert chain to every signed S/MIME e-mail is surely a
waste of bandwith. IMHO there should be an UI option to turn it off.
But it's a very easy way to distribute the cert chain and announce
the MUA's S/MIME capabilities.
> >Having recognized a signed S/MIME message with a self-signed certificate
> >(where the certificate is not already known to Mozilla) then Mozilla
> >could put up a special dialog box explaining the situation,
> >
> No popups please. They are intrusive. Why not just use another icon,
> e.g. one with a question mark? If the user clicks on it, we can explain
> what's the case and what the user can do.
Ben, if you don't like pop-ups the way in Comm. 4.x with accessing
the security panel by pushing [lock] is the way to go. It worked
pretty well although some verbal messages should be improved.
> >and then ask
> >the user if they know the sender and can verify the emssage came from
> >them. If the user says "yes", then the certificate would be marked as
> >trusted.
> >
> Another reason why this is not optimal: Maybe I want to ask (per email)
> a special question back to ensure that I'm talking to the right person.
> Or I want to call by phone in the evening and check the fingerprint. But
> a dialog has to be answered immediately.
1. The dialogue does not have to be answered immediately. It could
be similar to the one for unknown server certs. There's usually a
[Display Certificate] button shown where you can look at the
fingerprint. You can call the recipient by phone, verify the
fingerprint and proceed after having validated the certificate. But
it is very likely that the average user just hits the [Accept] or
[Next] button though => less security.
2. This whole stuff is mainly the reason for having trusted third
parties vouching for the identity checking. And because identity
checking is done remote and they might be in charge for doing this
wrong the process is pretty complex.
Ciao, Michael.
