Last Comment Bug 498443 - S/MIME interoperability problems with Eudora; add smime-type=enveloped-data parameter
: S/MIME interoperability problems with Eudora; add smime-type=enveloped-data p...
Status: RESOLVED FIXED
:
Product: MailNews Core
Classification: Components
Component: Security: S/MIME (show other bugs)
: Trunk
: All All
: -- normal with 2 votes (vote)
: Thunderbird 19.0
Assigned To: Sean Leonard
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-15 12:29 PDT by Sean Leonard
Modified: 2013-05-27 02:05 PDT (History)
16 users (show)
ryanvm: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Added smime-type=enveloped-data (1.86 KB, patch)
2011-12-14 12:56 PST, Sean Leonard
mozilla: review+
Details | Diff | Splinter Review

Description Sean Leonard 2009-06-15 12:29:31 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
Build Identifier: 2.0.0.21 (20090302)

Communicating signed and encrypted e-mail between Eudora 7.1.0.9 and Thunderbird exhibits interoperability problems.

In particular, the headers that Thunderbird emit are:

signed e-mail (signature part):

Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"

Enveloped e-mail:

Content-Type: application/x-pkcs7-mime; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"

Although close, these are not actually valid per S/MIME v3 (RFC 2633). As a result, Eudora does not recognize the message as valid S/MIME.

S/MIME v3 in RFC 2633 defines the content-types
application/pkcs7-mime
application/pkcs7-signature

(without the x- part)

Furthermore S/MIME v3 specifies the optional smime-type parameter for application/pkcs7-mime, which is set to enveloped-data or signed-data as the case may be. Although optional, this parameter is useful because some mail clients (e.g., Outlook) will interpret it before reading the contents. Therefore, the smime-type parameter should be added as well.

Reproducible: Always

Steps to Reproduce:
1. Send a message to a Eudora user in Thunderbird with S/MIME signature or encryption services applied.

Actual Results:  
1. Recipient cannot use the S/MIME features in Eudora with the message.

Expected Results:  
Recipient should be able to 

While some blame can be placed at Eudora's feet for not interpreting "application/x-pkcs7-mime" and "application/x-pkcs7-signature" "properly", in fact application/x-pkcs7-mime was never standardized in any S/MIME RFC. These types appeared in the first pre-release draft of S/MIME v2 (RFC 2311), but were quickly moved to an appendix (C.1).
Comment 1 Phil Ringnalda (:philor) 2009-06-15 13:40:46 PDT
Removing the x- is a duplicate of bug 436869, fixed long ago. Could you please try a 3.0 beta or nightly, see whether there's anything left you still want, and morph to be about that? (I see there's code that sticks smime-type params on, but I don't personally know whether/where it's actually used.)
Comment 2 Sean Leonard 2009-06-21 23:01:56 PDT
Thanks. I have tested with Thunderbird 3.0 nightly (20090621 3.0b3pre).

The types are properly serialized out as application/pkcs7-mime and application/pkcs7-signature. Thanks.

Nevertheless, the smime-type parameter is not added. I therefore request that this bug be morphed to add the appropriate smime-type parameter.

Although I have not fully groked the source code, it looks like the only change required is on line 587 of nsMsgComposeSecure.cpp:
add "; smime-type=enveloped-data" prior to the CRLF. (Or if you want, add a CRLF SPACE between ; and smime-type or whatever so it is not on one giant line.)

I am not sure if it is possible to emit opaque-signed data in Thunderbird, but it looks like not.

The rest of the code that mentions "smime-type" is either NSS test code, or is code for the (list) view of messages. Therefore, at least in theory Thunderbird should be able to use that information appropriately when reading its own messages.

Can this bug also be morphed to deal with the Eudora problem in the Eudora codebase, as Eudora only recognizes the MIME types without the "x-"? Has change control for Eudora been ceded to Mozilla?
Comment 3 David Ascher (:davida) 2009-08-10 15:49:30 PDT
Kai, do you know enough to judge the suggestion in comment #2? 

Denying blocking until we have more info from someone familiar w/ SMIME and the TB codebase =).
Comment 4 Kai Engert (:kaie) 2009-08-19 02:24:11 PDT
Sean, could you please give us a little bit background?

Is this the first time someone attempts to make Eudora and Thunderbird interoperable on the S/Mime level?

Or did this work in the past and this bug is a regression report?
Comment 5 Kai Engert (:kaie) 2009-08-19 02:25:33 PDT
If this is not a regression, I would suggest that Eudora attempts to understand what classic versions of Thunderbird sent, in order to achieve greater compatibility with installed software base.
Comment 6 Kai Engert (:kaie) 2009-08-19 02:35:58 PDT
(In reply to comment #2)
> Although I have not fully groked the source code, it looks like the only change
> required is on line 587 of nsMsgComposeSecure.cpp:
> add "; smime-type=enveloped-data" prior to the CRLF. (Or if you want, add a
> CRLF SPACE between ; and smime-type or whatever so it is not on one giant
> line.)

Sean, the source code changes over time, lines get moved. When you write statements like this, please always include some context or at least the exact line you want to change.

When I look at this file, line 587 is the blank line before function 
nsresult nsMsgComposeSecure::MimeInitEncryption(PRBool aSign, nsIMsgSendReport *sendReport)

I would like to propose, please give complete examples.

Please attach a message as it is being sent today (wrong in your opinion),
then manually alter that message to look according to your proposal and attach it, too.

This will make it easier for others to understand your proposed change.
Thanks
Comment 7 Kai Engert (:kaie) 2009-08-19 02:36:49 PDT
When you describe your change, please also describe why you believe your change is safe and remains compatible with other versions of Thunderbird.
Thanks.
Comment 8 Sean Leonard 2011-01-28 22:56:37 PST
Sorry about dropping the ball here--it looks like this never got confirmed.

I am now looking at the latest source code, namely, at:
http://mxr.mozilla.org/comm-central/source/mailnews/extensions/smime/src/nsMsgComposeSecure.cpp

The revision is f9d76929e7a4.

To give context: initially this bug was mainly about "application/x-pkcs7-mime" versus "application/pkcs7-mime". Eudora was not interpreting the x- variant. That problem, however, appears to have been fixed awhile ago.

The other part of this bug was to emit the "smime-type" parameter in the MIME headers. This parameter helps a decoder identify what kind of CMS entity it is, EnvelopedData or SignedData, without needing to invoke an ASN.1 parser to start to parse the inner contents.

We are now looking at
nsresult nsMsgComposeSecure::MimeInitEncryption(PRBool aSign, nsIMsgSendReport *sendReport)

specifically, at the lines after:
PR_smprintf("Content-Type: " APPLICATION_PKCS7_MIME

(which in this revision, is line 567, about 20 lines down)

The point is to add between lines 567 (see above) and line 568, the following line:
    "; smime-type=enveloped-data"

That's it. No need for more CRLF line breaks.

Compare with section 3.3 of RFC 2633.

Again, sorry for the long hiatus.
Comment 9 Ludovic Hirlimann [:Usul] 2011-02-10 07:56:29 PST
(In reply to comment #8)
> Sorry about dropping the ball here--it looks like this never got confirmed.
> 
> I am now looking at the latest source code, namely, at:
> http://mxr.mozilla.org/comm-central/source/mailnews/extensions/smime/src/nsMsgComposeSecure.cpp
> 
> The revision is f9d76929e7a4.
> 
> To give context: initially this bug was mainly about "application/x-pkcs7-mime"
> versus "application/pkcs7-mime". Eudora was not interpreting the x- variant.
> That problem, however, appears to have been fixed awhile ago.
> 
> The other part of this bug was to emit the "smime-type" parameter in the MIME
> headers. This parameter helps a decoder identify what kind of CMS entity it is,
> EnvelopedData or SignedData, without needing to invoke an ASN.1 parser to start
> to parse the inner contents.
> 
> We are now looking at
> nsresult nsMsgComposeSecure::MimeInitEncryption(PRBool aSign, nsIMsgSendReport
> *sendReport)
> 
> specifically, at the lines after:
> PR_smprintf("Content-Type: " APPLICATION_PKCS7_MIME
> 
> (which in this revision, is line 567, about 20 lines down)
> 
> The point is to add between lines 567 (see above) and line 568, the following
> line:
>     "; smime-type=enveloped-data"

Can you provide a patch to do that ?
Comment 10 Geri 2011-12-12 06:38:27 PST
The "missing smime-type" issue has not changed with TB 5.0.

Though this is not a MUST in S/MIME v3.2 the following is stated at the end of section 3.2 of RFC 5751:

"Because there are several types of application/pkcs7-mime objects, a sending agent SHOULD do as much as possible to help a receiving agent know about the contents of the object without forcing the receiving agent to decode the ASN.1 for the object.  The Content-Type header field of all application/pkcs7-mime objects SHOULD include the optional "smime-type" parameter, as described in the following sections."

Without such a proper smime-type parameter one has to dive into the content to find the proper type, which is everything else than convenient.
Comment 11 Geri 2011-12-12 06:56:15 PST
PS: It's still the same with TB 8.0.
Comment 12 Sean Leonard 2011-12-14 12:56:10 PST
Created attachment 581756 [details] [diff] [review]
Added smime-type=enveloped-data

This patch fixes the smime-type=enveloped-data absence. Let's get it in.
Comment 13 Mark Banner (:standard8) 2011-12-14 16:57:53 PST
Comment on attachment 581756 [details] [diff] [review]
Added smime-type=enveloped-data

All patches require review before they can be landed. See these pages for more details:

https://developer.mozilla.org/en/Code_Review_FAQ
https://developer.mozilla.org/en/Mailnews_and_Mail_code_review_requirements

I'll request review from Kai as I think that's most appropriate here.
Comment 14 sunmoon51 2012-01-30 11:41:17 PST
I'd like to support Comment #10 and mention the bug is still present in TB 9.0.1. The issue isn't a matter of Eudora-TB compatability but rather of the possibility to send S/MIME secured mail using TB. For instance, I've found the problem trying to send S/MIME mail to the user of the newest Horde/Imp MUA. Horde S/MIME code expects "smime-type=enveloped-data" parameter presence and in case of it's absence simply doesn't decrypt the message. In my opinion the patch is needed ASAP.
Comment 15 Philipp Kern 2012-03-20 06:06:12 PDT
So Kai argued that others should get compatible with Thunderbird.  Well mutt tries that:

 /* Netscape 4.7 uses 
  * Content-Description: S/MIME Encrypted Message
  * instead of Content-Type parameter
  */
  if (!ascii_strcasecmp (m->description, "S/MIME Encrypted Message"))
    return SMIMEENCRYPT;

The thing is: Thunderbird translates that string.  So first of all it doesn't send the smime-type which is specified in the RFC, but secondly it breaks others who go the extra step to detect Netscape proprietary S/MIME handling and then the string's translated:

Content-Description: S/MIME Verschlüsselte Nachricht

The umlaut ü is not even properly encoded, so it does send 8bit characters in the header.  I realize that this may be considered a different bug, but adding smime-type support would of course solve those issues once and for all.

Please tell me if I need to file a different bug to at least get the Content-Description translation issue fixed in time.

(The sender uses TB 10.0 with lang=de.)
Comment 16 Kai Engert (:kaie) 2012-08-15 01:22:39 PDT
Comment on attachment 581756 [details] [diff] [review]
Added smime-type=enveloped-data

sorry, I don't have time to focus on this.
Comment 17 Honza Bambas (:mayhemer) 2012-10-26 08:52:19 PDT
Comment on attachment 581756 [details] [diff] [review]
Added smime-type=enveloped-data

I'm no expert to S/MIME unfortunately, however the change looks good to me.  Rather delegating to David Bienvenu.
Comment 18 David :Bienvenu 2012-10-27 11:44:54 PDT
Comment on attachment 581756 [details] [diff] [review]
Added smime-type=enveloped-data

seems reasonable to me - we should just be looking out for any interoperability regressions.
Comment 19 Ryan VanderMeulen [:RyanVM] 2012-10-27 14:54:47 PDT
https://hg.mozilla.org/comm-central/rev/bed310fd6408

Thanks for the patch, Sean! Sorry for the horrible lag in getting it checked in :(
Comment 20 Laurent Blin 2013-05-23 13:10:25 PDT
Any way to add this patch in the next version? Do we have to wait thunderbird 19? 
As for now, I can't send encrypted email to another trusted company, because of the smime-type=enveloped-data field missing (they reject our mails).
Regards
Comment 21 Ludovic Hirlimann [:Usul] 2013-05-27 02:05:51 PDT
Thunderbird 19 is out in beta since a long time. You'l have to wait for 24 to get it on stable ...

Note You need to log in before you can comment on or make changes to this bug.