545509 - Thunderbird should cope with signed emails without an email address

Status: NEW

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

Description

[Bob Lord]

Some organizations do not put emails into the certs they issue, often because people move around frequently and that changes their email address.

Thunderbird should be able to validate emails that are signed with a cert that does not contain an email address.  Further, it should allow users to reply to such emails, and initiate new emails, to those recipients.

Comment 1

[Eddy Nigg (StartCom)]

I don't think that's a particular good idea. S/MIME supports multiple email addresses in the SAN extension if needed.

Comment 2

[Bob Lord]

For these customers, people often move around on a regular and unpredictable basis.  Their certificates are issued onto smartcards, and issuing a new certificate involves a face-to-face operation at a limited number of sites.

Comment 3

[Daniel Veditz [:dveditz]]

So are you wanting Thunderbird to invent a non-standard S/MIME? That's not going to work with other S/MIME clients, is it?

Comment 4

[Bob Lord]

(In reply to comment #3)
> So are you wanting Thunderbird to invent a non-standard S/MIME? That's not
> going to work with other S/MIME clients, is it?

Your question is valid in terms of real-world deployments. 

Here is the RFC: http://www.ietf.org/rfc/rfc3850.txt
===
3.  Using Distinguished Names for Internet Mail

   End-entity certificates MAY contain an Internet mail address as
   described in [RFC-2822].  The address must be an "addr-spec" as
   defined in Section 3.4.1 of that specification.  The email address
   SHOULD be in the subjectAltName extension, and SHOULD NOT be in the
   subject distinguished name.

-->Receiving agents MUST recognize and accept certificates that contain
   no email address.  Agents are allowed to provide an alternative
   mechanism for associating an email address with a certificate that
   does not contain an email address, such as through the use of the
   agent's address book, if available. 
   ...
===

A related problem is that sometimes the sender's email address and the email address in the cert are not the same. I get mail on a regular basis from people with an email address like [e-mail], where "crt" mean "contractor". That's what gets sent out from their mail servers, but that's not always what is inside their certificate. So TB shows a problem since the email addresses do not match. To mitigate that problem, they have a plugin for Outlook that does something like what is requested in Bug 539928.