Automatic retrieval of certificates (S/MIME)

Automatic retrieval of certificates (S/MIME)

[Stefan Kamphausen]

Hi,

today I've been playing around with the S/MIME stuff in Gnus.  While
it all works as expected there is one glitch that I can't fix anyhow.

When I send a message to a friend using his certificate to encrypt and
mine to sign the message I have to explicitly state which certificate
to use for signing (at least this is filled with a reasonable default
from smime-keys) and which for encryption (this is just a
read-file-name on the smime-certificate-directory.  It would be very
nice if those were picked according to the recipients email adress
taken from the "To:"-header and the "From:" adress respectively.

Furthermore the sending of the message keeps asking me for another
round of signature and encryption certificate.  This time it's for the
saving of the message in the Gcc-Header (at least I think I found that
by doing some experiments, giving the false encryption argument leads
to my not being able to decrypt the message when viewing my
sent-box).  The most confusing part in this is that I can't see from
the prompts or the message display for which recipient I have to give
the encryption key.

Am I missing something here?  I've dived into mml-sec.el and
mml-smime.el and I think that the insertion of the mml statement
_might_ already contain the certificates but maybe I just didn't
understand it.

Any help/pointers to docs/examples appreciated
Thanks and Regards
Stefan  (new to Gnus, sorry if stupid)
-- 
Stefan Kamphausen --- http://www.skamphausen.de
GPG: http://www.skamphausen.de/pubkey-mail-skamphausen-de
     fingerprint = 785C 6CF8 72B3 FB32 6145  7FBA 2FE0 3C63 A03B C3C9
a blessed +42 regexp of confusion (weapon in hand)
You hit. The format string crumbles and turns to dust.

Re: Automatic retrieval of certificates (S/MIME)

[Simon Josefsson]

Stefan Kamphausen <skampi@gmx.de> writes:

> Hi,
>
> today I've been playing around with the S/MIME stuff in Gnus.  While
> it all works as expected there is one glitch that I can't fix anyhow.
>
> When I send a message to a friend using his certificate to encrypt and
> mine to sign the message I have to explicitly state which certificate
> to use for signing (at least this is filled with a reasonable default
> from smime-keys) and which for encryption (this is just a
> read-file-name on the smime-certificate-directory.  It would be very
> nice if those were picked according to the recipients email adress
> taken from the "To:"-header and the "From:" adress respectively.

Yes, although I'm not sure how to implement that.  Mapping e-mail
addresses to S/MIME certificates is not well standardized under Unix.
There is no per-user S/MIME directory on the local machine to use.

If you want to think about how this would work, and perhaps implement
it, that would be very useful.

> Furthermore the sending of the message keeps asking me for another
> round of signature and encryption certificate.  This time it's for the
> saving of the message in the Gcc-Header (at least I think I found that
> by doing some experiments, giving the false encryption argument leads
> to my not being able to decrypt the message when viewing my
> sent-box).  The most confusing part in this is that I can't see from
> the prompts or the message display for which recipient I have to give
> the encryption key.

Your analysis is correct.  There is a variable that you can set so the
GCC'd copy contain the raw MML tags instead of the encoded version.
The reason for encoding things twice is that encoding a message for
mail/news is in theory different from encoding it for GCC.  The same
formatting logic cannot always be used.  So that's why Gnus encode the
message twice.  It is arguable a bug.  On the other hand, a better
solution might be to make S/MIME sign/encrypt so smooth that you
wouldn't care that it is encoded twice.

If you want what is sent through mail, you can use 'Bcc' instead of
'Gcc'.

> Am I missing something here?  I've dived into mml-sec.el and
> mml-smime.el and I think that the insertion of the mml statement
> _might_ already contain the certificates but maybe I just didn't
> understand it.

You can specify the key/cert in the MML tags, if that is what you
meant.  See 'MML Definition' in the Emacs MIME manual.  You can say,
e.g.:

<#part sign=smime keyfile="~/cacert.user.key">

Hm.  I now realize that part of what you are wishing for is already
implemented for the S/MIME partial signing.  When I pressed "Secure
MIME Part" -> "S/MIME Sign Part" it automatically added the 'keyfile'
parameter, because my smime-keys variable says:

 '(smime-keys (quote (("simon@josefsson.org" "~/certs/jas.key+cert" nil) ("jas@extundo.com" "~/cacert.user.key" ("~/cacert.crt")) ("sj@extundo.com" "~/certs/sj.key+cert" nil))))

Can you try if

<#!secure method=smime mode=sign keyfile="foo">

works?  If so, perhaps you can locate the code that add the keyfile
parameter to the MIME part tags, and add it to the full-message MML
tag code.

Re: Automatic retrieval of certificates (S/MIME)

[David S. Goldberg]

[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]

>>>>> On Thu, 27 Jan 2005 19:33:02 +0100, Simon Josefsson
>>>>> <jas@extundo.com> said:

> Yes, although I'm not sure how to implement that.  Mapping e-mail
> addresses to S/MIME certificates is not well standardized under Unix.
> There is no per-user S/MIME directory on the local machine to use.

> If you want to think about how this would work, and perhaps implement
> it, that would be very useful.

It's not trivial.  At work we keep keys in an LDAP database and I use
EUDC to fetch those I need into a local directory.  Then I've got some
helper functions I wrote (attached to the end of this message) that
map the addresses in the To and CC headers to keys in the directory,
verify the keys, and build the necessary mml.  The main entry point
for signing and encrypting is dsg-message-smime-message.  This works
fine for me, but I expect it's not a general solution.

> Your analysis is correct.  There is a variable that you can set so the
> GCC'd copy contain the raw MML tags instead of the encoded version.
> The reason for encoding things twice is that encoding a message for
> mail/news is in theory different from encoding it for GCC.  The same
> formatting logic cannot always be used.  So that's why Gnus encode the
> message twice.  It is arguable a bug.  On the other hand, a better
> solution might be to make S/MIME sign/encrypt so smooth that you
> wouldn't care that it is encoded twice.

I also find it annoying to have to type my passphrase twice per
message.  I keep hearing that gpg will soon support s/mime.  If/when
that happens, would the pgg interface then take care of this?

> You can specify the key/cert in the MML tags, if that is what you
> meant.  See 'MML Definition' in the Emacs MIME manual.  You can say,
> e.g.:

> <#part sign=smime keyfile="~/cacert.user.key">

I use <#multipart> which ends up being a complete replacement the
<#secure> tag in that the signature applies to the entire message.
I've never got the <#secure> tat to work if there are multiple
recipients.

-- 
Dave Goldberg
david.goldberg6@verizon.net

[-- Attachment #2: Type: application/emacs-lisp, Size: 9750 bytes --]

Re: Automatic retrieval of certificates (S/MIME)

[Simon Josefsson]

david.goldberg6@verizon.net (David S. Goldberg) writes:

> I also find it annoying to have to type my passphrase twice per
> message.  I keep hearing that gpg will soon support s/mime.

It supposedly already does, but I haven't gotten it to work completely
enough to write an Emacs interface for it.

> If/when that happens, would the pgg interface then take care of
> this?

No, but a separate Gnus<->gpgsmime interface could be written.

Also, the current smime.el could perhaps be extended to use
password.el to do password caching.

>> You can specify the key/cert in the MML tags, if that is what you
>> meant.  See 'MML Definition' in the Emacs MIME manual.  You can say,
>> e.g.:
>
>> <#part sign=smime keyfile="~/cacert.user.key">
>
> I use <#multipart> which ends up being a complete replacement the
> <#secure> tag in that the signature applies to the entire message.
> I've never got the <#secure> tat to work if there are multiple
> recipients.

It might be a bug.

Re: Automatic retrieval of certificates (S/MIME)

[David S. Goldberg]

>>>>> On Sat, 05 Feb 2005 12:25:12 +0100, Simon Josefsson
>>>>> <jas@extundo.com> said:

>> If/when that happens, would the pgg interface then take care of
>> this?

> No, but a separate Gnus<->gpgsmime interface could be written.

Darn :-)

> Also, the current smime.el could perhaps be extended to use
> password.el to do password caching.

Hmmm.  That might be something even I could try to implement.

>>> You can specify the key/cert in the MML tags, if that is what you
>>> meant.  See 'MML Definition' in the Emacs MIME manual.  You can say,
>>> e.g.:
>> 
>>> <#part sign=smime keyfile="~/cacert.user.key">
>> 
>> I use <#multipart> which ends up being a complete replacement the
>> <#secure> tag in that the signature applies to the entire message.
>> I've never got the <#secure> tat to work if there are multiple
>> recipients.

> It might be a bug.

I've asked about this on the ding-list a couple times over the years.
If there is a bug, it's that, when using the <#secure> tag it only
ever prompts for one key and it never tells you for which recipient
it's prompting.  Last time I brought it up I attempted to understand
the code and add that capability.  I never was able to, and so went
with building my own solution.

-- 
Dave Goldberg
david.goldberg6@verizon.net