S/MIME support

S/MIME support

[Ulf Stegemann]

Hi,

since S/MIME seems to spread more and more (at least among the people I
communicate with) I'd like to ask if there are any plans to enhance Gnus'
S/MIME support.

I haven't been able to follow the Gnus development very closely since the
release of 5.10.6 nor have I tried any of the development releases for a long
time.  Thus, my observations refer to 5.10.6.  A quick look at the relevant
newsgroups did not reveal any messages on that topic lately.  Furthermore
smime.el and mml-smime.el haven't changed very much since 5.10.6.

First of all: S/MIME works, i.e. signing/encrypting and verifying/decrypting
does not pose a problem.  However, compared to PGP S/MIME handling is rather
clumsy.

To me, the biggest problem when using S/MIME with Gnus is the key
(certificate) management.  This may not be Gnus' fault since an appropriate
external tool for S/MIME certificate management (like GnuPG for PGP keys)
seems to be missing.  I've once seen a tool called smime-keys that comes with
mutt but this one offers rather basic functions.  Currently there's no
auto-magical selection of recipient certificates and no 'encrypt-to-self'
(although, macros could help here).  The absence of appropriate S/MIME tools
leaves the question if it's reasonable to build something using elisp or if
it's better to wait for something like gpgsm to become more stable/usable and
use such a tool with Gnus.

Furthermore, LDAP support is a nice thing to have with S/MIME (especially for
CRLs).  Maybe, eudc could help here?

To summerize it: Gnus' S/MIME support is rather rudimentary.  Other user
agents (especially those that come with browser suits) outdo Gnus regarding
S/MIME.  S/MIME seems to/may become more and more important.

Regarding that, is it worth it to think about improving Gnus' S/MIME
capabilities?  Are there plans to do so?  Or is it all a very bad idea and
are there more important things to do?


Regards,

Ulf

-- 
Obscure RFCs you may not be aware of, part v:
RFC 2325 - Definitions of Managed Objects for Drip-Type Heated Beverage
           Hardware Devices using SMIv2

Re: S/MIME support

[Simon Josefsson]

Ulf Stegemann <ulf@zeitform.de> writes:

> Regarding that, is it worth it to think about improving Gnus' S/MIME
> capabilities?  Are there plans to do so?  Or is it all a very bad idea and
> are there more important things to do?

I think it would be useful to enhance it.  However, I believe the
first step toward making the support better is to replace OpenSSL with
the S/MIME implementation in the development versions of GnuPG; gpgsm.
I don't think OpenSSL is a good idea.  I believe gpgsm can help with
the key management issues you mention as well.

Re: S/MIME support

[Werner Koch]

On Wed, 01 Sep 2004 10:53:37 +0200, Simon Josefsson said:

> the S/MIME implementation in the development versions of GnuPG; gpgsm.
> I don't think OpenSSL is a good idea.  I believe gpgsm can help with
> the key management issues you mention as well.

The interface of gpgsm is very similar to gpg and thus it should be no
problem to add support for it to pgg.  Note however that gpgsm does
not take a passphrase because private keys are entirely managed by the
gpg-agent and thus gpg-agent will pop up a pinentry dialog as needed -
gpg also support the gpg-agent. (There is a curses based pinentry
available).

Just ask me if you need help integrating gpgsm into Gnus; I know the
gpgsm very well ;-).


Shalom-Salam,

   Werner

Re: S/MIME support

[Simon Josefsson]

Werner Koch <wk@gnupg.org> writes:

> On Wed, 01 Sep 2004 10:53:37 +0200, Simon Josefsson said:
>
>> the S/MIME implementation in the development versions of GnuPG; gpgsm.
>> I don't think OpenSSL is a good idea.  I believe gpgsm can help with
>> the key management issues you mention as well.
>
> The interface of gpgsm is very similar to gpg and thus it should be no
> problem to add support for it to pgg.  Note however that gpgsm does
> not take a passphrase because private keys are entirely managed by the
> gpg-agent and thus gpg-agent will pop up a pinentry dialog as needed -
> gpg also support the gpg-agent. (There is a curses based pinentry
> available).

Good.  It is probably a bad idea to force all applications to do its
own password handling, so having gpg-agent handle the password instead
of Gnus sounds better anyway.

(This reminds me that generalizing gpg-agent would be good... I have
wanted to use something similar in Shishi/SASL too.  And I recall
Nikos wanting to use it in GNUTLS, but I never started working on it.
Gnus' password.el could use it as well, perhaps.)

> Just ask me if you need help integrating gpgsm into Gnus; I know the
> gpgsm very well ;-).

I'm working on the integration.  See my questions on gnupg-users. :-)

Thanks,
Simon

Re: S/MIME support

[Werner Koch]

On Mon, 06 Sep 2004 14:25:44 +0200, Simon Josefsson said:

> (This reminds me that generalizing gpg-agent would be good... I have
> wanted to use something similar in Shishi/SASL too.  And I recall

We have ssh support by supporting the ssh-agent protocol in the
GNUPG-1-9-BRANCH-MO of gnupg ;-)

  Werner

Re: S/MIME support

[Miles Bader]

Simon Josefsson <jas@extundo.com> writes:
>> Note however that gpgsm does not take a passphrase because private
>> keys are entirely managed by the gpg-agent and thus gpg-agent will
>> pop up a pinentry dialog as needed - gpg also support the
>> gpg-agent. (There is a curses based pinentry available).
>
> Good.  It is probably a bad idea to force all applications to do its
> own password handling, so having gpg-agent handle the password instead
> of Gnus sounds better anyway.

What would it do if you were running on a terminal?!?

-Miles
-- 
自らを空にして、心を開く時、道は開かれる

Re: S/MIME support

[Simon Josefsson]

Miles Bader <miles@gnu.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>>> Note however that gpgsm does not take a passphrase because private
>>> keys are entirely managed by the gpg-agent and thus gpg-agent will
>>> pop up a pinentry dialog as needed - gpg also support the
>>> gpg-agent. (There is a curses based pinentry available).
>>
>> Good.  It is probably a bad idea to force all applications to do its
>> own password handling, so having gpg-agent handle the password instead
>> of Gnus sounds better anyway.
>
> What would it do if you were running on a terminal?!?

Dunno.  Does gpg-agent support this?  If not, gpgsm.el have to supply
gpgsm with a password somehow.  Or you could store the private keys
unencrypted on disk...

Re: S/MIME support

[Werner Koch]

On Fri, 10 Sep 2004 08:56:03 +0900, Miles Bader said:

> What would it do if you were running on a terminal?!?

There is a plain curses version of pinentry and the standard pinentry
falls back to curses if $DISPLAY is not set.  The application should
better redraw its screen after calling gpgsm; curses might not be able to
save and restore the background.

  Werner