Frederick Roeber wrote on a generalized certificate scheme (quoting Ben
Bucksch):
> > But this would imply, that one (mostly) reimplements OpenPGP for PSM
> > or NSS, right?
>
> Probably, depending on how tightly the "math" is tied up with the
> mechanism. One thing that was very high on my list was the ability to
> store PGP keys (and ssh, btw) on standard cryptoki tokens (even if the
> token couldn't support them natively).
I think this is a worthy feature to consider at some point in the
future, and it is definitely good to have PSM and NSS be general enough
to allow an OpenPGP implementation to be included with as part of
PSM/NSS. However I agree with Ben and others that for now at least the
better approach is simply to provide some way for existing OpenPGP
implementations to integrate into Mozilla mail/news. People are already
using such implementations, they have existing key databases, and they
are doing OpenPGP stuff in contexts outside Mozilla (e.g., file
encryption).
However at the same time hopefully there _will_ be a native S/MIME
implementation in Mozilla. (And for the record, I believe there is room
for both S/MIME support with Mozilla and OpenPGP support with Mozilla; I
think the two protocols serve different markets and different types of
users.)
Given that, I would like to see the flexibility of S/MIME certificate
handling in PSM/NSS expanded to allow easy use of self-signed
certificates with Mozilla mail/news. I think the following are the key
features required to do this right:
* 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.
* 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. 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 -- you have to have some knowledge of public key
cryptography and S/MIME in order to make the connection between sending
a signed message and enabling the recipient to send you encrypted email.
I am not sure what the best interface for this action would be, or where
it should go in the overall UI. 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. This would
auto-generate a signed message with some pre-formatted text explaining
to the recipient what the purpose of the message is. The message could
be automatically sent or (my preference) Mozilla could simply bring up a
message composition window with the "signed" box already checked and the
recipient, subject line, and body text filled in; the user could then
add additional comments as desired.
* Provide a straightforward procedure to recognize an incoming S/MIME
message signed with a self-signed certificate and allow the user to mark
the certificate as trusted. Again, the existing way to do this is not
intuitive; the user has to know to look at S/MIME messages with
"untrusted issuers" for the certificate, and specifically mark the
certificate as trusted. Instead Mozilla should be able to specifically
recognize S/MIME signed messages with self-signed certificates, and
distinguish them from the more general case of an unknown CA. (Which
should be possible, right -- just look for certificates where the
subject public key = the CA public key.)
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, 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.
* 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.
> Note that at the time, we'd have had to reimplement PGP anyway, to get
> an MPL'd version. That still might be necessary, unfortunately, but
> that's a question for the mozilla policy people.
As Ben noted, there are already mechanisms in place by which GPG and
similar applications can be invoked without raising license issues.
> Such a ground-up effort is probably way overkill for the simple goal of
> supporting PGP in Mozilla. That could probably be more easily done with
> two independant implementations, and the cracks plastered over with UI..
Agreed.
Frank
--
Frank Hecker work: http://www.collab.net/
[EMAIL PROTECTED] home: http://www.hecker.org/
