539928 - Support S/MIME certificates with mis-matched email address (e.g. as SupressNameChecks in MS Outlook)

Status: UNCONFIRMED

(MailNews Core :: Security: S/MIME, enhancement)

Description

[vargok]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7
Build Identifier: Thunderbird 2.x and 3.x - all

Support a (non-default) configuration-based option to allow for sending S/MIME messages to email addresses which don't match the certificate.  This is analogous to the Outlook option 'SupressNameChecks'.
While this is a sub-optimal solution, unfortunately, there are organizations which are not going to change their practice of using mis-matched email accounts and certificates.

For instance, even if using an LDAP directory to store all information, including the SMIME certificate, Thunderbird will refused to send encrypted email to the certificate on the record matching that mail: if the email address in the certificate does not match the email address to which mail is being sent.

Reproducible: Always

Steps to Reproduce:
1.  Attempt to send S/MIME encrypted email to a user
2.  User's certificate does not have the same email encoded into it
3.
Actual Results:  
Thunderbird complains about not being able to find a proper certificate.
"You specified encryption for this message, but the application failed to find an encryption certificate for [actual email address]"

Expected Results:  
Once the new option is sent, email is encrypted to the certificate and sent.

Comment 1

[Ludovic Hirlimann [:Usul]]

Isn't that just defeating the use of S/mime certs and encryption ?

Bob is this a valid request ?

Comment 2

[vargok]

While not desired, RFC2632 states:
---
   Sending agents SHOULD make the address in the From or Sender header
   in a mail message match an Internet mail address in the signer's
   certificate. Receiving agents MUST check that the address in the From
   or Sender header of a mail message matches an Internet mail address
   in the signer's certificate, if mail addresses are present in the
   certificate. A receiving agent SHOULD provide some explicit alternate
   processing of the message if this comparison fails, which may be to
   display a message that shows the recipient the addresses in the
   certificate or other certificate details.
---
i.e., it's bad behavior, but permissible.

Comment 3

[Kai Engert [:KaiE:]]

Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody.
Search for kaie-20100607-unconfirmed-nobody

Comment 4

[Edwin soto]

I can confirm that this is still occurring with at least one user.

Mac OSX 10.6.8
Thunderbird ver. 12.0.1

After installing Thunderbird add on for DoD, still unable to open encrypted messages. This addon install Root Certificates.

Tools & Resources: Download DoD Mozilla Firefox & Thunderbird Add-ons
http://www.forge.mil/Resources-Firefox.html

The sender included their certificate (.cer) which we are able to add but still get the error: "Although the digital signature is valid, it is unknown whether sender and signer are the same person. The certificate used to sign the message does not contain an email address."

All of it makes sense as the email address author of the certificate does not match the sender.

Unfortunately, this has become a standard practice for many DoD addresses (.mil).

Any further information about this bug's history would be appreciated.

Comment 5

[R Talbott]

I too can confirm this is an issue;

I found that Apple MAIL can not encrypt an EMAIL even if the person's certificate is in keychain, valid, and marked for always trust.  MAIL grays out the padlock if the EMAIL addresses do not match.

Microsoft outlook appears to be the only mail app that has a way to override.

Comment 6

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

Comment 8

[Kai Engert [:KaiE:]]

We can consider to make this possible, but it needs a lot of user interface changes. We'd have to support it for configuring, sending and displaying. Lots of changes that would be different from the current expectations. And we'd have to carefully think about how to present the state of a signature to the user, if it mismatches.

Comment 9

[Robert Hartmann]

Just to ask - any additional information about the time horizont?