287396 - Directory lookup of PKI certificates fails when the certificate does not contain the mail address

Status: RESOLVED EXPIRED

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

Description

[Simon Woods]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Thunderbird version 1.0+ (20050322) - nightly build

The vast majority of the Siemens PKI certificates do not contain the mail
address of the addresse. This causes problems when sending encrypted mail to
such users. It is possible to add the users certificate to the store, however
the lookup in the address book fails. More importantly however the lookup via
ldap also fails, despite the fact that the ldap server returns a certificate for
the user.

Reproducible: Always

Steps to Reproduce:
1. Configure thunderbird to use the address book: ldap://cl.siemens.com:389 base
directory: o=Trustcenter

2. Try to send an encrypted mail to [e-mail]

Actual Results:  
Thunderbird responds with "... application failed to find an encryption
certificate for simon.woods..."

Expected Results:  
Downloaded the certificate from the ldap server and used this to encrypt the mail

See also http://www.siemens.com/pki for further details.

Comment 1

[Daniel Veditz [:dveditz]]

My reading of the spec (rfc 2312 section 3.1) seems to say certs have to have
the address to be valid for S/MIME

   End-entity certificates MUST contain an Internet mail address as
   described in [RFC-822]. The address must be an "addr-spec" as defined
   in Section 6.1 of that specification.
 ...
   Sending agents SHOULD make the address in the From header in a mail
   message match an Internet mail address in the signer's certificate.

But booting to the mail guys who may know if this is superseded.

Comment 2

[Daniel Veditz [:dveditz]]

My bad, rfc 2312 is S/MIME version 2. In rfc 2632 (S/MIME version 3) this was
updated to read

  End-entity certificates MAY contain an Internet mail address...

Better let the S/MIME guys have their say in this bug.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

The mozilla email clients presently require email addresses in certs.
This is necessary for security in the situation where the browser is going
to pick a cert and encrypt with it, without having the user examine the 
cert visually to ensure it is the cert for the right recipient. 

If Alice's email client sends off a request to a remote LDAP server, asking 
"give me the cert for user [e-mail]" and it gets back a cert and then 
uses it for encryption without verifying that the certified subject name 
contains [e-mail], such a scheme is vulnerable to MITM attacks.  
Evil Eve, whose computer sits between Alice's email client and the remote 
LDAP server, can simply send HER own cert to Alice's email client, then 
Alice encrypts the message using Eve's public key, and Eve intercepts it
and reads it, then encrypts it in Bob's real public key and sends it on to
Bob.  

So, Alice's email client must either (a) be able to verify that the cert 
belongs to the recipient by comparing certified into in the cert with
information that Alice entered into the client (e.g. Bob's email address), 
or else (b) present the cert to Alice and ask her to confirm that this is 
Bob's cert, before relying on it to send encrypted email.  

AFAIK, mozilla email clients do not presently have the UI to present the
cert to Alice and ask her to verify that it is Bob's cert.  So, they 
rely on automatically verifiable email address info.  

It is possible that in this case, mozilla is asking the LDAP directory
for Bob's cert, but upon receiving it, finds that it cannot verify that 
the cert belongs to Bob.  In other words, we don't know that there is an
LDAP failure here.  There may or may not be.  But there is almost 
certainly a failure of automatic cert identity verification because the
cert doesn't contain info that matches the email address that Alice typed.

Comment 4

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 5

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.