The default bug view has changed. See this FAQ.

S/MIME interoperability problems with Eudora; add smime-type=enveloped-data parameter

RESOLVED FIXED in Thunderbird 19.0

Status

MailNews Core
Security: S/MIME
RESOLVED FIXED
8 years ago
4 years ago

People

(Reporter: Sean Leonard, Assigned: Sean Leonard)

Tracking

Trunk
Thunderbird 19.0
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

8 years ago
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).
(Assignee)

Updated

8 years ago
Component: General → Security
Flags: wanted1.8.1.x?
Flags: wanted-thunderbird3?
Flags: blocking-thunderbird3?
Version: unspecified → 2.0
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.)
Component: Security → Security: S/MIME
Product: Thunderbird → MailNews Core
QA Contact: general → s.mime
Version: 2.0 → 1.8 Branch
(Assignee)

Comment 2

8 years ago
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?
Summary: S/MIME interoperability problems with Eudora; set Content-Types per S/MIME v3; add smime-type parameter → S/MIME interoperability problems with Eudora; add smime-type parameter
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 =).
Flags: blocking-thunderbird3? → blocking-thunderbird3-

Comment 4

8 years ago
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

8 years ago
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

8 years ago
(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

8 years ago
When you describe your change, please also describe why you believe your change is safe and remains compatible with other versions of Thunderbird.
Thanks.
(Assignee)

Comment 8

6 years ago
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.
(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

5 years ago
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

5 years ago
PS: It's still the same with TB 8.0.

Updated

5 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: S/MIME interoperability problems with Eudora; add smime-type parameter → S/MIME interoperability problems with Eudora; add smime-type=enveloped-data parameter
(Assignee)

Comment 12

5 years ago
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.
Attachment #581756 - Flags: approval-comm-release?
Attachment #581756 - Flags: approval-comm-beta?
Attachment #581756 - Flags: approval-comm-aurora?
(Assignee)

Updated

5 years ago
Version: 1.8 Branch → Trunk
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.
Attachment #581756 - Flags: review?(kaie)
Attachment #581756 - Flags: approval-comm-release?
Attachment #581756 - Flags: approval-comm-beta?
Attachment #581756 - Flags: approval-comm-aurora?

Updated

5 years ago
Assignee: nobody → dev+mozilla
Status: NEW → ASSIGNED
Flags: wanted1.8.1.x?
Flags: wanted-thunderbird3?
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: [one liner patch]

Comment 14

5 years ago
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

5 years ago
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

5 years ago
Comment on attachment 581756 [details] [diff] [review]
Added smime-type=enveloped-data

sorry, I don't have time to focus on this.
Attachment #581756 - Flags: review?(kaie) → review?
Attachment #581756 - Flags: review? → review?(honzab.moz)
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.
Attachment #581756 - Flags: review?(honzab.moz) → review?(mozilla)

Comment 18

5 years ago
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.
Attachment #581756 - Flags: review?(mozilla) → review+

Updated

5 years ago
Keywords: checkin-needed
https://hg.mozilla.org/comm-central/rev/bed310fd6408

Thanks for the patch, Sean! Sorry for the horrible lag in getting it checked in :(
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Flags: blocking-thunderbird3- → in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 19.0
Keywords: checkin-needed
Whiteboard: [one liner patch]

Comment 20

4 years ago
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
Thunderbird 19 is out in beta since a long time. You'l have to wait for 24 to get it on stable ...
You need to log in before you can comment on or make changes to this bug.