399690 - NSS uses least specific email address from subject DN, not most specific

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect, P3)

Description

[Nelson Bolyard (seldom reads bugmail)]

In bug 392790, Kaspar Brand observed that NSS fetches the least specific 
(most general) email address from a cert's subject name, rather than 
the most specific email address.  It does this in numerous places.  
See http://lxr.mozilla.org/security/search?string=rawEmailAddr+%3D+CERT_GetName
for a list of them.

Long ago, for Bug 197964, I fixed CERT_GetCommonName to get the most-specific 
common name, in accordance with RFC 2818, which requires that. 

I don't know of any RFC that imposes a similar requirement on email addresses,
but it surely seems reasonable.  

Indeed, one wonders if all or most of the functions in alg1485.c that call 
CERT_GetNameElement (which gets the least specific name) should be changed
to instead call CERT_GetLastNameElement (which gets the most specific name).

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Attachment: change all assignments to rawEmailAddr to use CERT_GetLastNameElement

I fear that changing this after 10+ years of it being wrong is going to break
lots of stuff.  :-(

Please review.

Comment 2

[Kaspar]

Comment on attachment 284733 [details] [diff] [review]
change all assignments to rawEmailAddr to use CERT_GetLastNameElement

r-, for several reasons:

1. As you're surmising already, it breaks backwards compatibility for NSS based applications, most notably for Thunderbird and Seamonkey. For a certificate with multiple addresses in the subject only, current versions of these applications consider the first ("most generic") when matching against the From header (and only the first, they will ignore the others). If this is changed, the verification results between older and newer releases will differ - previous releases would no longer be able to verify messages signed by the current versions. Quite confusing for users.

2. It breaks interoperability with at least one other popular S/MIME-enabled mail client. Outlook Express (and even Windows Mail, its successor on Vista) verifies based on the first PKCS#9 email address in the subject DN, only.

3. There is no RFC (or even I-D) I know of which stipulates that it's the right thing to only use the "most specific" email address (i.e. the last when looking at the ASN.1 SEQUENCE).

4. For cert_GetCertificateEmailAddresses(), this is not the proper fix. Instead of replacing CERT_GetNameElement() by CERT_GetLastNameElement(), it should be changed to fetch *all* RDNs with SEC_OID_PKCS9_EMAIL_ADDRESS/SEC_OID_RFC1274_MAIL. [This might be worth a separate fix, though.]

5. I don't see any benefit from changing this (other than making the code more consistent with the handling of multiple commonName RDNs), and the patch modifies the behavior for a legacy feature which has been deprecated by the S/MIME RFCs for at least eight years.

Comment 3

[Robert Relyea]

Comment on attachment 284733 [details] [diff] [review]
change all assignments to rawEmailAddr to use CERT_GetLastNameElement

The modern suggestion is to put email addresses in subject alt names, I think we can live without this patch.