Re: attachments in S/MIME encrypted messages

Re: attachments in S/MIME encrypted messages

[David S. Goldberg]

>>>>> On Fri, 12 Oct 2001 17:36:06 +0200, Simon Josefsson
>>>>> <jas@extundo.com> said: 

Resurecting a dead horse...

> david.goldberg6@verizon.net (David S. Goldberg) writes:
>> I just tried it on XEmacs 21.1.14 under cygwin, which I rarely use or
>> I'd have thought of it before, and it mostly worked right once I got
>> all the cert files properly mirrored on my laptop.  The verification
>> process claimed forgery even on messages I sent and signed myself but
>> the resulting article buffer was properly buttonized.  I'm in the
>> process of upgrading XEmacs for Solaris to see if that solves the
>> buttonizing problem there, and if so I'll check on the verification
>> thing.  I'm running openssl 0.9.5 under cygwin which may be an issue
>> there.

> There _is_ a CRLF bug in Gnus (I just became aware of this), but it is
> in the encoding part, so shouldn't affect this.  I have little time to
> look at this now, but hopefully a interoperability testing project
> with the various open mail clients could be started soon, then we
> should be able to detect these problems better.

I finally upgraded to XEmacs 21.4.6.  I discovered that there's a new
(or at least newly documented) option to configure called
--with-file-coding which I enabled on Sun (it's on by default under
cygwin) and that solves the CRLF issues.  Encrypted emails are
properly parsed under both Sun and cygwin now.  I still get a "Sender
address forged" message in the button of a decrypted message in spite
of openssl clearly getting successful verification, but that's much
less of a concern since clicking the button provides me that info.

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: attachments in S/MIME encrypted messages

[Simon Josefsson]

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

>> There _is_ a CRLF bug in Gnus (I just became aware of this), but it is
>> in the encoding part, so shouldn't affect this.  I have little time to
>> look at this now, but hopefully a interoperability testing project
>> with the various open mail clients could be started soon, then we
>> should be able to detect these problems better.
>
> I finally upgraded to XEmacs 21.4.6.  I discovered that there's a new
> (or at least newly documented) option to configure called
> --with-file-coding which I enabled on Sun (it's on by default under
> cygwin) and that solves the CRLF issues.

Ah.  So there is a MULE bug somewhere.  I always enable that stuff,
which probably explains why I couldn't reproduce it.  I'll try to
compile without it sometime, thanks.

> I still get a "Sender address forged" message in the button of a
> decrypted message in spite of openssl clearly getting successful
> verification, but that's much less of a concern since clicking the
> button provides me that info.

You need a recent OpenSSL, but even with that sometimes the -email
switch to OpenSSL doesn't get the email address.  Maybe it is when the
email address is encoded in the CN instead of stored in a
subjectAltName extension.

Re: attachments in S/MIME encrypted messages

[Simon Josefsson]

Simon Josefsson <jas@extundo.com> writes:

> david.goldberg6@verizon.net (David S. Goldberg) writes:
>
>>> There _is_ a CRLF bug in Gnus (I just became aware of this), but it is
>>> in the encoding part, so shouldn't affect this.  I have little time to
>>> look at this now, but hopefully a interoperability testing project
>>> with the various open mail clients could be started soon, then we
>>> should be able to detect these problems better.
>>
>> I finally upgraded to XEmacs 21.4.6.  I discovered that there's a new
>> (or at least newly documented) option to configure called
>> --with-file-coding which I enabled on Sun (it's on by default under
>> cygwin) and that solves the CRLF issues.
>
> Ah.  So there is a MULE bug somewhere.  I always enable that stuff,
> which probably explains why I couldn't reproduce it.  I'll try to
> compile without it sometime, thanks.

I was able to reproduce it and fixed that problem.  Thanks.

Re: attachments in S/MIME encrypted messages

[Simon Josefsson]

Simon Josefsson <jas@extundo.com> writes:

> david.goldberg6@verizon.net (David S. Goldberg) writes:
>
>>> There _is_ a CRLF bug in Gnus (I just became aware of this), but it is
>>> in the encoding part, so shouldn't affect this.  I have little time to
>>> look at this now, but hopefully a interoperability testing project
>>> with the various open mail clients could be started soon, then we
>>> should be able to detect these problems better.
>>
>> I finally upgraded to XEmacs 21.4.6.  I discovered that there's a new
>> (or at least newly documented) option to configure called
>> --with-file-coding which I enabled on Sun (it's on by default under
>> cygwin) and that solves the CRLF issues.
>
> Ah.  So there is a MULE bug somewhere.  I always enable that stuff,
> which probably explains why I couldn't reproduce it.  I'll try to
> compile without it sometime, thanks.

I was able to reproduce it and fixed that problem.  Thanks.

Re: attachments in S/MIME encrypted messages

[David S. Goldberg]

>>>>> On Mon, 04 Mar 2002 19:37:53 +0100, Simon Josefsson
>>>>> <jas@extundo.com> said:

> Ah.  So there is a MULE bug somewhere.  I always enable that stuff,
> which probably explains why I couldn't reproduce it.  I'll try to
> compile without it sometime, thanks.

Maybe, but I had the same problem with a MULE-enabled XEmacs 21.1.14
though since I know nothing of MULE, I just built it and ran without
modifying my .emacs so I may have missed a setting that would have
solved the problem then.

> You need a recent OpenSSL, but even with that sometimes the -email
> switch to OpenSSL doesn't get the email address.  Maybe it is when the
> email address is encoded in the CN instead of stored in a
> subjectAltName extension.

I'm running openssl 0.9.6c but most, if not all the messages in
question all are generated by Netscape.  Messages that are only signed
verify OK, but perhaps netscape does something different when it's
encrypted.  I'll try to debug it.

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: attachments in S/MIME encrypted messages

[Simon Josefsson]

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

>> Ah.  So there is a MULE bug somewhere.  I always enable that stuff,
>> which probably explains why I couldn't reproduce it.  I'll try to
>> compile without it sometime, thanks.
>
> Maybe, but I had the same problem with a MULE-enabled XEmacs 21.1.14

But without --with-file-coding enabled, right?  When I built without
--with-file-coding I also got CRLFs.

>> You need a recent OpenSSL, but even with that sometimes the -email
>> switch to OpenSSL doesn't get the email address.  Maybe it is when the
>> email address is encoded in the CN instead of stored in a
>> subjectAltName extension.
>
> I'm running openssl 0.9.6c but most, if not all the messages in
> question all are generated by Netscape.  Messages that are only signed
> verify OK, but perhaps netscape does something different when it's
> encrypted.  I'll try to debug it.

Just run OpenSSL on the certificates in the S/MIME blob:

openssl smime -pk7out < mail > foo
openssl pkcs7 -print_certs -text < foo > bar
openssl x509 -email -noout < bar

try it with different messages and see when the last command doesn't
output the email address from the cert.

Re: attachments in S/MIME encrypted messages

[David S. Goldberg]

>>>>> On Mon, 04 Mar 2002 22:00:43 +0100, Simon Josefsson
>>>>> <jas@extundo.com> said: 

> david.goldberg6@verizon.net (David S. Goldberg) writes:
>> Maybe, but I had the same problem with a MULE-enabled XEmacs 21.1.14

> But without --with-file-coding enabled, right?  When I built without
> --with-file-coding I also got CRLFs.

Right.  Under 21.1.14 I don't see --with-file-coding available as a
configure option (when I run configure --help).  However a look into
the configure script itself shows that it's there.

I just fired up a 21.1.14 (no mule, no file-coding) to try to read an
encrypted message to check your fix and got this backtrace (lines
wrapped by me):

Signaling: (wrong-number-of-arguments
	    #<compiled-function
	    (prompt table &optional predicate
		    require-match initial-contents
		    history) "...(37)"
		    [table predicate require-match t nil
			   last-exact-completion minibuffer-completion-confirm
			   minibuffer-completion-predicate
			   minibuffer-completion-table read-from-minibuffer
			   prompt
			   initial-contents minibuffer-local-completion-map
			   minibuffer-local-must-match-map history] 6 756283>
			   7)
completing-read("Decipher using which key? (default dsg@mitre.org) "
		(("dsg@mitre.org"
		  "/afs/rcf/user/dsg/private/certs/dsg-20020208-20030802.pem")
		 ("old-dsg@mitre.org"
		  "/afs/rcf/user/dsg/private/certs/dsg-20000817-20020208.pem")
		 ("oldest-dsg@mitre.org"
		  "/afs/rcf/user/dsg/private/certs/dsg-19990224-20000817.pem"))
		nil nil nil nil "dsg@mitre.org")
mm-view-pkcs7-decrypt((#<buffer " *mm*<2>">
				("application/x-pkcs7-mime"
				 (name . "smime.p7m")) base64 nil
				 ("attachment" (filename . "smime.p7m"))
				 "S/MIME Encrypted Message" nil nil))
mm-view-pkcs7((#<buffer " *mm*<2>"> ("application/x-pkcs7-mime"
				     (name . "smime.p7m")) base64 nil
				     ("attachment" (filename . "smime.p7m"))
				     "S/MIME Encrypted Message" nil nil))
mm-possibly-verify-or-decrypt((#<buffer " *mm*<2>">
					("application/x-pkcs7-mime"
					 (name . "smime.p7m")) base64 nil
					 ("attachment"
					  (filename . "smime.p7m"))
					 "S/MIME Encrypted Message" nil nil)
			      ("application/x-pkcs7-mime"
			       (name . "smime.p7m")))
mm-dissect-buffer(nil nil)
gnus-display-mime()
gnus-article-prepare-display()
gnus-article-prepare(8040 nil)
gnus-summary-display-article(8040 nil)
gnus-summary-select-article(nil force)
gnus-summary-show-article(nil)
call-interactively(gnus-summary-show-article)

Which seems odd.  It works just fine in 21.4.6.

> Just run OpenSSL on the certificates in the S/MIME blob:

> openssl smime -pk7out < mail > foo
> openssl pkcs7 -print_certs -text < foo > bar
> openssl x509 -email -noout < bar

> try it with different messages and see when the last command doesn't
> output the email address from the cert.

Hmm.  If "mail" is just signed the last one works fine.  If "mail" is
encrypted it barfs (the result of the previous command is empty,
which doesn't surprise me somehow :-), but if I decrypt mail first and
work on the decrypted output it works OK.

-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: attachments in S/MIME encrypted messages

[David S. Goldberg]

>>>>> On Tue, 05 Mar 2002 11:40:54 -0500, david.goldberg6@verizon.net
>>>>> (David S. Goldberg) said:

> Hmm.  If "mail" is just signed the last one works fine.  If "mail" is
> encrypted it barfs (the result of the previous command is empty,
> which doesn't surprise me somehow :-), but if I decrypt mail first and
> work on the decrypted output it works OK.

A bit of edebugging and I basically understand the mistaken forgery
business now.  The problem is that mm-handle-multipart-from is
returning nil when working on the (signed) output of a decryption
where as it's getting the From address when working on a cleartext
signed message.  I see that mm-handle-multipart-from is a macro that
simply looks for a text property so I conclude that when decryption is
needed first the text property is not getting set.  Unfortunately I
have a very little understanding of text properties and have thus far
been unable to figure out where it's getting set when reading the
signed message so I can't say why it's not happening on the decrypted
buffer.

-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: attachments in S/MIME encrypted messages

[David S. Goldberg]

>>>>> On Tue, 05 Mar 2002 11:40:54 -0500, david.goldberg6@verizon.net
>>>>> (David S. Goldberg) said:

> Hmm.  If "mail" is just signed the last one works fine.  If "mail" is
> encrypted it barfs (the result of the previous command is empty,
> which doesn't surprise me somehow :-), but if I decrypt mail first and
> work on the decrypted output it works OK.

A bit of edebugging and I basically understand the mistaken forgery
business now.  The problem is that mm-handle-multipart-from is
returning nil when working on the (signed) output of a decryption
where as it's getting the From address when working on a cleartext
signed message.  I see that mm-handle-multipart-from is a macro that
simply looks for a text property so I conclude that when decryption is
needed first the text property is not getting set.  Unfortunately I
have a very little understanding of text properties and have thus far
been unable to figure out where it's getting set when reading the
signed message so I can't say why it's not happening on the decrypted
buffer.

-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: attachments in S/MIME encrypted messages

[David S. Goldberg]

>>>>> On Mon, 04 Mar 2002 22:00:43 +0100, Simon Josefsson
>>>>> <jas@extundo.com> said: 

> david.goldberg6@verizon.net (David S. Goldberg) writes:
>> Maybe, but I had the same problem with a MULE-enabled XEmacs 21.1.14

> But without --with-file-coding enabled, right?  When I built without
> --with-file-coding I also got CRLFs.

Right.  Under 21.1.14 I don't see --with-file-coding available as a
configure option (when I run configure --help).  However a look into
the configure script itself shows that it's there.

I just fired up a 21.1.14 (no mule, no file-coding) to try to read an
encrypted message to check your fix and got this backtrace (lines
wrapped by me):

Signaling: (wrong-number-of-arguments
	    #<compiled-function
	    (prompt table &optional predicate
		    require-match initial-contents
		    history) "...(37)"
		    [table predicate require-match t nil
			   last-exact-completion minibuffer-completion-confirm
			   minibuffer-completion-predicate
			   minibuffer-completion-table read-from-minibuffer
			   prompt
			   initial-contents minibuffer-local-completion-map
			   minibuffer-local-must-match-map history] 6 756283>
			   7)
completing-read("Decipher using which key? (default dsg@mitre.org) "
		(("dsg@mitre.org"
		  "/afs/rcf/user/dsg/private/certs/dsg-20020208-20030802.pem")
		 ("old-dsg@mitre.org"
		  "/afs/rcf/user/dsg/private/certs/dsg-20000817-20020208.pem")
		 ("oldest-dsg@mitre.org"
		  "/afs/rcf/user/dsg/private/certs/dsg-19990224-20000817.pem"))
		nil nil nil nil "dsg@mitre.org")
mm-view-pkcs7-decrypt((#<buffer " *mm*<2>">
				("application/x-pkcs7-mime"
				 (name . "smime.p7m")) base64 nil
				 ("attachment" (filename . "smime.p7m"))
				 "S/MIME Encrypted Message" nil nil))
mm-view-pkcs7((#<buffer " *mm*<2>"> ("application/x-pkcs7-mime"
				     (name . "smime.p7m")) base64 nil
				     ("attachment" (filename . "smime.p7m"))
				     "S/MIME Encrypted Message" nil nil))
mm-possibly-verify-or-decrypt((#<buffer " *mm*<2>">
					("application/x-pkcs7-mime"
					 (name . "smime.p7m")) base64 nil
					 ("attachment"
					  (filename . "smime.p7m"))
					 "S/MIME Encrypted Message" nil nil)
			      ("application/x-pkcs7-mime"
			       (name . "smime.p7m")))
mm-dissect-buffer(nil nil)
gnus-display-mime()
gnus-article-prepare-display()
gnus-article-prepare(8040 nil)
gnus-summary-display-article(8040 nil)
gnus-summary-select-article(nil force)
gnus-summary-show-article(nil)
call-interactively(gnus-summary-show-article)

Which seems odd.  It works just fine in 21.4.6.

> Just run OpenSSL on the certificates in the S/MIME blob:

> openssl smime -pk7out < mail > foo
> openssl pkcs7 -print_certs -text < foo > bar
> openssl x509 -email -noout < bar

> try it with different messages and see when the last command doesn't
> output the email address from the cert.

Hmm.  If "mail" is just signed the last one works fine.  If "mail" is
encrypted it barfs (the result of the previous command is empty,
which doesn't surprise me somehow :-), but if I decrypt mail first and
work on the decrypted output it works OK.

-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: attachments in S/MIME encrypted messages

[Simon Josefsson]

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

>> Ah.  So there is a MULE bug somewhere.  I always enable that stuff,
>> which probably explains why I couldn't reproduce it.  I'll try to
>> compile without it sometime, thanks.
>
> Maybe, but I had the same problem with a MULE-enabled XEmacs 21.1.14

But without --with-file-coding enabled, right?  When I built without
--with-file-coding I also got CRLFs.

>> You need a recent OpenSSL, but even with that sometimes the -email
>> switch to OpenSSL doesn't get the email address.  Maybe it is when the
>> email address is encoded in the CN instead of stored in a
>> subjectAltName extension.
>
> I'm running openssl 0.9.6c but most, if not all the messages in
> question all are generated by Netscape.  Messages that are only signed
> verify OK, but perhaps netscape does something different when it's
> encrypted.  I'll try to debug it.

Just run OpenSSL on the certificates in the S/MIME blob:

openssl smime -pk7out < mail > foo
openssl pkcs7 -print_certs -text < foo > bar
openssl x509 -email -noout < bar

try it with different messages and see when the last command doesn't
output the email address from the cert.

Re: attachments in S/MIME encrypted messages

[David S. Goldberg]

>>>>> On Mon, 04 Mar 2002 19:37:53 +0100, Simon Josefsson
>>>>> <jas@extundo.com> said:

> Ah.  So there is a MULE bug somewhere.  I always enable that stuff,
> which probably explains why I couldn't reproduce it.  I'll try to
> compile without it sometime, thanks.

Maybe, but I had the same problem with a MULE-enabled XEmacs 21.1.14
though since I know nothing of MULE, I just built it and ran without
modifying my .emacs so I may have missed a setting that would have
solved the problem then.

> You need a recent OpenSSL, but even with that sometimes the -email
> switch to OpenSSL doesn't get the email address.  Maybe it is when the
> email address is encoded in the CN instead of stored in a
> subjectAltName extension.

I'm running openssl 0.9.6c but most, if not all the messages in
question all are generated by Netscape.  Messages that are only signed
verify OK, but perhaps netscape does something different when it's
encrypted.  I'll try to debug it.

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: attachments in S/MIME encrypted messages

[Simon Josefsson]

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

>> There _is_ a CRLF bug in Gnus (I just became aware of this), but it is
>> in the encoding part, so shouldn't affect this.  I have little time to
>> look at this now, but hopefully a interoperability testing project
>> with the various open mail clients could be started soon, then we
>> should be able to detect these problems better.
>
> I finally upgraded to XEmacs 21.4.6.  I discovered that there's a new
> (or at least newly documented) option to configure called
> --with-file-coding which I enabled on Sun (it's on by default under
> cygwin) and that solves the CRLF issues.

Ah.  So there is a MULE bug somewhere.  I always enable that stuff,
which probably explains why I couldn't reproduce it.  I'll try to
compile without it sometime, thanks.

> I still get a "Sender address forged" message in the button of a
> decrypted message in spite of openssl clearly getting successful
> verification, but that's much less of a concern since clicking the
> button provides me that info.

You need a recent OpenSSL, but even with that sometimes the -email
switch to OpenSSL doesn't get the email address.  Maybe it is when the
email address is encoded in the CN instead of stored in a
subjectAltName extension.

Re: attachments in S/MIME encrypted messages

[David S. Goldberg]

>>>>> On Fri, 12 Oct 2001 17:36:06 +0200, Simon Josefsson
>>>>> <jas@extundo.com> said: 

Resurecting a dead horse...

> david.goldberg6@verizon.net (David S. Goldberg) writes:
>> I just tried it on XEmacs 21.1.14 under cygwin, which I rarely use or
>> I'd have thought of it before, and it mostly worked right once I got
>> all the cert files properly mirrored on my laptop.  The verification
>> process claimed forgery even on messages I sent and signed myself but
>> the resulting article buffer was properly buttonized.  I'm in the
>> process of upgrading XEmacs for Solaris to see if that solves the
>> buttonizing problem there, and if so I'll check on the verification
>> thing.  I'm running openssl 0.9.5 under cygwin which may be an issue
>> there.

> There _is_ a CRLF bug in Gnus (I just became aware of this), but it is
> in the encoding part, so shouldn't affect this.  I have little time to
> look at this now, but hopefully a interoperability testing project
> with the various open mail clients could be started soon, then we
> should be able to detect these problems better.

I finally upgraded to XEmacs 21.4.6.  I discovered that there's a new
(or at least newly documented) option to configure called
--with-file-coding which I enabled on Sun (it's on by default under
cygwin) and that solves the CRLF issues.  Encrypted emails are
properly parsed under both Sun and cygwin now.  I still get a "Sender
address forged" message in the button of a decrypted message in spite
of openssl clearly getting successful verification, but that's much
less of a concern since clicking the button provides me that info.

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net

attachments in S/MIME encrypted messages

[David S. Goldberg]

I've been very happy with the S/MIME support for signing and verifying
sigs for a couple months now.  Today I got an S/MIME encrypted message
from my boss.  `W s' properly asked me for which key to use for
decryption (I've got two) and the passphrase and nicely decrypted the
message.  The problem was that the message is also a MIME structure
and that is not processed.  As such, the attachment I needed to
download was not easily accessible.  Is this something just not yet
implemented or is there something missing from my configuration?

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: attachments in S/MIME encrypted messages

[Simon Josefsson]

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

> I've been very happy with the S/MIME support for signing and verifying
> sigs for a couple months now.  Today I got an S/MIME encrypted message
> from my boss.  `W s' properly asked me for which key to use for
> decryption (I've got two) and the passphrase and nicely decrypted the
> message.  The problem was that the message is also a MIME structure
> and that is not processed.  As such, the attachment I needed to
> download was not easily accessible.  Is this something just not yet
> implemented or is there something missing from my configuration?

I dunno, it works for me. 

Does `K b' still only shows one button?

Maybe you could run the raw article through

openssl smime -in MAIL -decrypt -recip YOURKEY

or something to make sure it contains (a properly formatted)
attachment?

Or experiment by sending yourself a encrypted mail with an attachment
to see if it works (that's how I tested it).  Maybe there is something
in how some other mailer handle encrypted multiparts.

Re: attachments in S/MIME encrypted messages

[David S. Goldberg]

>> and doing `W s' on this part decrypted it and verified the signature.
>> Hm, maybe your problem is with verifying signatures.  If you remove
>> the first line above, does things work?

> I'll try without signing and see what happens but most people here who
> encrypt also sign so I need to be able to deal with it.

I tried without signing and had the same results except instead of a
raw multipart/signed, I got a raw multipart/mixed.  Strangely enough
if I just sign a message, verification seems to work OK.  It also
works fine for messages signed by others.
-- 
Dave Goldberg
david.goldberg6@verizon.net