S/MIME

S/MIME

[Bruce Stephens]

The PGP/MIME and S/MIME stuff looks like it's developing quickly.  I
can already sign messages with S/MIME.  (Actually, I could do that a
while ago, but it's nice to have it integrated into the main CVS
tree.)

How do I verify signatures?  I just get the error that
application/x-pkcs7-signed (or something like that) is unknown?  I can
see there's code that might work, but I can't see how to tie up the
hooks.

Re: S/MIME

[ShengHuo ZHU]

Bruce Stephens <bruce+gnus@cenderis.demon.co.uk> writes:

> The PGP/MIME and S/MIME stuff looks like it's developing quickly.  I
> can already sign messages with S/MIME.  (Actually, I could do that a
> while ago, but it's nice to have it integrated into the main CVS
> tree.)
> 
> How do I verify signatures?  I just get the error that
> application/x-pkcs7-signed (or something like that) is unknown?  I can
> see there's code that might work, but I can't see how to tie up the
> hooks.

Verification and decryption of S/MIME have not been implemented yet.
You could (setq mm-verify-option 'known) and 
(setq mm-decrypt-option 'known) to ignore the message.

ShengHuo

Re: S/MIME

[Simon Josefsson]

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

Bruce Stephens <bruce+gnus@cenderis.demon.co.uk> writes:

> How do I verify signatures?  I just get the error that
> application/x-pkcs7-signed (or something like that) is unknown?

S/MIME signature verification should work now.  Unfortunately S/MIME
doesn't use multipart/encrypted (rfc 2015), so there's a little more
work involved getting decryption to work too.  Shouldn't take too long
though.

I'm signing this so that you can check if it works.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 1515 bytes --]

Re: S/MIME

[ShengHuo ZHU]

Simon Josefsson <sj@extundo.com> writes:

> Bruce Stephens <bruce+gnus@cenderis.demon.co.uk> writes:
> 
> > How do I verify signatures?  I just get the error that
> > application/x-pkcs7-signed (or something like that) is unknown?
> 
> S/MIME signature verification should work now.  Unfortunately S/MIME
> doesn't use multipart/encrypted (rfc 2015), so there's a little more
> work involved getting decryption to work too.  Shouldn't take too long
> though.

Two possible problems:

1. The output of openssl may contain ^M's.  At least, I found one at
   the end of the first MIME boundary. I don't know why.  Should those
   ^M's be removed?

2. When smime-verify-buffer is called, the article headers have been
   decoded, which means that users may have to pick a coding system to
   encode those non-ASCII characters before it is sent to openssl.  It
   would be better to copy the article to a new buffer, and remove
   unnecessary headers, or just narrow to the article body.

ShengHuo

Re: S/MIME

[Simon Josefsson]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> 1. The output of openssl may contain ^M's.  At least, I found one at
>    the end of the first MIME boundary. I don't know why.  Should those
>    ^M's be removed?

OpenSSL problem, fixed in 0.9.6.  I believe the signature isn't
calculated over the boundary so this shouldn't cause any problems, I
think.

> 2. When smime-verify-buffer is called, the article headers have been
>    decoded, which means that users may have to pick a coding system to
>    encode those non-ASCII characters before it is sent to openssl.  It
>    would be better to copy the article to a new buffer, and remove
>    unnecessary headers, or just narrow to the article body.

Right.  I added mm-handle-multipart-* to get information of a MIME
multipart, and it's used by mml-smime-verify now.  What do you think,
is the copying too costly?

I think the proper solution would be to add a reference to the "upper"
MIME object within a MIME handle.  I'm not sure how to do that in
elisp though.  The uppermost MIME handle should also include a
reference to the RFC822 article headers too, because the "From:" line
should be verified to match the certificate used to sign a message.

Also, what should happen when verification fails?  For S/MIME it print
a message saying if the verification was successful or not, PGP/MIME
doesn't seem to print anything, and display a *MML2015* buffer if the
verification fail.  Neither is very intuitive if you got 100 signed
parts in a mail.  I think it would be nice if verification/decryption
status was displayed such as

[text/plain; signed (S/MIME): Undecided]
[text/plain; signed (S/MIME): OK]
[text/plain; signed (S/MIME): Failed]

and you could pop up the menu and get some kind of "Security info" for
that MIME part, with more details.

Re: S/MIME

[ShengHuo ZHU]

Simon Josefsson <sj@extundo.com> writes:

> Right.  I added mm-handle-multipart-* to get information of a MIME
> multipart, and it's used by mml-smime-verify now.  What do you think,
> is the copying too costly?

What kind of information mml-smime-verify needs? CTL, From and To?

> I think the proper solution would be to add a reference to the "upper"
> MIME object within a MIME handle.  I'm not sure how to do that in
> elisp though.  The uppermost MIME handle should also include a
> reference to the RFC822 article headers too, because the "From:" line
> should be verified to match the certificate used to sign a message.

"From:" line could be saved in a dynamic variable when
mm-dissect-buffer is called without no-strict-mime, like what I did in
PGP/MIME encryption.

> Also, what should happen when verification fails?  For S/MIME it print
> a message saying if the verification was successful or not, PGP/MIME
> doesn't seem to print anything, and display a *MML2015* buffer if the
> verification fail.  Neither is very intuitive if you got 100 signed
> parts in a mail.  I think it would be nice if verification/decryption
> status was displayed such as

> [text/plain; signed (S/MIME): Undecided]
> [text/plain; signed (S/MIME): OK]
> [text/plain; signed (S/MIME): Failed]
> 
> and you could pop up the menu and get some kind of "Security info" for
> that MIME part, with more details.

It sounds good to me.  I suggest to forge attributes `gnus-info' and
`gnus-details' in content-disposition.

ShengHuo

Re: S/MIME

[Simon Josefsson]

On 5 Nov 2000, ShengHuo ZHU wrote:

> What kind of information mml-smime-verify needs? CTL, From and To?

I looked at SMIMEv2 and SMIMEv3 specs but I can't find the reference to
looking at From: and comparing it to certificate owner.  Perhaps that's 
simply obvious, altough I can think of some issues (use
X.509 subjectAlternateName or not? etc).  Ok; CTL is required, From will
be needed, To will be needed by encryption/decryption.

Verifying signatures without checking that the sender == signer is of
course bad.  OpenSSL doesn't seem to perform this checking (although it
has "-from" and "-to") so we have to do it ourself. Hm, are there any
ASN.1 libraries written in elisp?  We'd might use 
`ssl-certificate-information' of ssl.el as an easier solution.

S/MIME suggestions

[Bruce Stephens]

Just a couple of suggestions for signed email mostly.  Most user
agents don't *require* that certificates verify (i.e., you don't
*have* to have the issuer's certificate).  They complain loudly if the
certificate doesn't validate, obviously, but they allow you to trust a
specific certificate, without having to trust all certificates signed
by a particular issuer.

Openssl allows this using the -noverify flag.  So (in a pleasantly
contradictory fashion), "openssl smime -verify -noverify ..." makes
perfect sense.

Also, "openssl smime -verify ... -signer <file>" extracts the
certificate (presuming there is one).  That strikes me as a very
convenient feature to use.  Especially considering that "openssl x509
-email -noout -in <cert>.pem" prints out a list of email addresses for
the given certificate, which would presumably allow Gnus to check that
the email addresses match with the From header.

Re: S/MIME suggestions

[Simon Josefsson]

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

Bruce Stephens <bruce+gnus@cenderis.demon.co.uk> writes:

> Just a couple of suggestions for signed email mostly.  Most user
> agents don't *require* that certificates verify (i.e., you don't
> *have* to have the issuer's certificate).  They complain loudly if the
> certificate doesn't validate, obviously, but they allow you to trust a
> specific certificate, without having to trust all certificates signed
> by a particular issuer.
> 
> Openssl allows this using the -noverify flag.  So (in a pleasantly
> contradictory fashion), "openssl smime -verify -noverify ..." makes
> perfect sense.

Yes.  What would good defaults be?  First try to verify
message+certificate, with fall back to simply verify the message?  In
the second case, it could say something along the lines of

[[S/MIME Signed: OK (Untrusted CA))]]

What do you think?

> Also, "openssl smime -verify ... -signer <file>" extracts the
> certificate (presuming there is one).  That strikes me as a very
> convenient feature to use.  Especially considering that "openssl x509
> -email -noout -in <cert>.pem" prints out a list of email addresses for
> the given certificate, which would presumably allow Gnus to check that
> the email addresses match with the From header.

I've added support for this now.

This message should be an example of this, if you got the verisign
cert in your CA path, it should say "Sender forged" (you might need to
do `W s' if you disabled auto-verification).  If you click on the
button it should display the certificate found in this message so you
can spot why it happened.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 1515 bytes --]

Re: S/MIME suggestions

[Bruce Stephens]

Simon Josefsson <jas@extundo.com> writes:

> Bruce Stephens <bruce+gnus@cenderis.demon.co.uk> writes:

[...]

> > Openssl allows this using the -noverify flag.  So (in a pleasantly
> > contradictory fashion), "openssl smime -verify -noverify ..." makes
> > perfect sense.
> 
> Yes.  What would good defaults be?  First try to verify
> message+certificate, with fall back to simply verify the message?
> In the second case, it could say something along the lines of
> 
> [[S/MIME Signed: OK (Untrusted CA))]]
> 
> What do you think?

Yes, probably.  The way Outlook Express does it (by default) is a bit
OTT, but it expresses the various possibilities.  When you open a
signed and/or encrypted message, you get a screen with a number of
items on it, with ticks or crosses by them.  I forget exactly the
list, but it'll include things like "signature verifies", "certificate
trusted", "certificate issuer trusted", "certificate subject matches
from address", and so on.  (Things for expiry, too, I guess.)

Then you need to click again to get to the message (which is what
sucks---Netscrape does this much less intrusively, and much more
appropriately, IMHO---also, when it's an encrypted message that you
can't decrypt, it won't even show you the (unencrypted) headers, which
is really dumb).

However, there seem to be a number of possibilities.  I think I'd like
to be able to trust a CA, but still be warned if something signed by a
certificate issued by it (i.e., I'd have a list of generally trusted
CAs, but mostly I'd explicitly trust individual certificates).

Anyway, this is making real progress---S/MIME support seems to be
approaching PGP's in usability.

> > Also, "openssl smime -verify ... -signer <file>" extracts the
> > certificate (presuming there is one).  That strikes me as a very
> > convenient feature to use.  Especially considering that "openssl x509
> > -email -noout -in <cert>.pem" prints out a list of email addresses for
> > the given certificate, which would presumably allow Gnus to check that
> > the email addresses match with the From header.
> 
> I've added support for this now.
> 
> This message should be an example of this, if you got the verisign
> cert in your CA path, it should say "Sender forged" (you might need to
> do `W s' if you disabled auto-verification).  If you click on the
> button it should display the certificate found in this message so you
> can spot why it happened.

OK, I'll try reading it when I've updated my Gnus.

Re: S/MIME suggestions

[ShengHuo ZHU]

Simon Josefsson <jas@extundo.com> writes:

[...]

> I've added support for this now.

A possible error:

,----
| While compiling the end of the data in file /u/zsh/s/gnus/lisp/smime.el:
|   ** the function point-at-eol is not known to be defined.
`----

ShengHuo

Re: S/MIME suggestions

[Kai Großjohann]

On 29 Nov 2000, ShengHuo ZHU wrote:

> A possible error:
> 
> ,----
> | While compiling the end of the data in file /u/zsh/s/gnus/lisp/smime.el:
> |   ** the function point-at-eol is not known to be defined.
> `----

gnus-point-at-eol is probably Simon's friend.

kai
-- 
The arms should be held in a natural and unaffected way and never
be conspicuous. -- Revised Technique of Latin American Dancing

Re: S/MIME suggestions

[Simon Josefsson]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> | While compiling the end of the data in file /u/zsh/s/gnus/lisp/smime.el:
> |   ** the function point-at-eol is not known to be defined.

Fixed, thanks.

Re: S/MIME suggestions

[Simon Josefsson]

Bruce Stephens <bruce+gnus@cenderis.demon.co.uk> writes:

> Yes, probably.  The way Outlook Express does it (by default) is a bit
> OTT, but it expresses the various possibilities.  When you open a
> signed and/or encrypted message, you get a screen with a number of
> items on it, with ticks or crosses by them.  I forget exactly the
> list, but it'll include things like "signature verifies", "certificate
> trusted", "certificate issuer trusted", "certificate subject matches
> from address", and so on.  (Things for expiry, too, I guess.)

That's too obtrusive imho, but there should be a menu or something on
the security button so one could list all details of a signed part.

> Anyway, this is making real progress---S/MIME support seems to be
> approaching PGP's in usability.

Deciphering S/MIME messages doesn't work though.  Mainly because
S/MIME didn't use RFC 1847.  Sigh.  I have a sort-of working elisp
ASN.1 library now, that is able to parse those PKCS#7 blobs and find
out what they are.  I'll check it in soon..

Re: S/MIME suggestions

[Simon Josefsson]

Bruce Stephens <bruce+gnus@cenderis.demon.co.uk> writes:

> Openssl allows this using the -noverify flag.  So (in a pleasantly
> contradictory fashion), "openssl smime -verify -noverify ..." makes
> perfect sense.

I've implemented & commited this now -- which means that everyone with
OpenSSL 0.9.6 should be able to verify the integrity of S/MIME
messages without any configuration.  To additionally be able to
authenticate identity of a sender, one needs to populate
`smime-CA-file' or `smime-CA-directory' with something you trust (or
not, or whatever).