Frank Hecker wrote:
>* Have a straightforward "one click" procedure to allow a user to
>generate a private key, public key, and self-signed X.509v3 certificate
>all in Mozilla, with no third-party communication (i.e., with a CA)
>required. This could be offered as an option when creating a Mozilla
>profile and/or a new Mozilla mail account.
>
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
Ideally, the default in the Account Wizard would be to generate a new
self-signed key. But there are 2 problems:
* Per Mailnews team, the Account Wizard should only have the minimal
options required for setting up an account. (It doesn't even allow
to set "Advanced" IMAP setting, which causes some severe UI
problems, but that's another topic.) Maybe somebody from the
Netscape Mailnews group can make a statement to this.
* 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.
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.)
>* Provide a straightforward procedure to send another user your public
>key (read: your self-signed X.509v3 certificate) so that they can then
>send you encrypted email.
>
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.
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.
Problem: What should be done, when no cert can be found? Should the user
send unencrpted then? SaveAsDraft, ask recipient for cert manually, then
resend?
>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.
>Perhaps this could be integrated with
>the address book? In other words, select a person in your address book
>and then click a button to send them your public key.
>
Good idea.
>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.
>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.
>* Provide an easy way to have signing and/or encryption automatically
>turned on for certain recipients or classes of recipients (e.g., all
>users in your own domain, for intra-company email). IMO this is very
>similar to the problem of enabling HTML email -- you want to make the
>capability easily discoverable and easy to turn on, but prevent users
>from sending such "non-standard" email in contexts where the recipients
>can't or don't want to receive it.
>
*nod*
