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 Simon.Woods@mch.sbs.de 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.
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.
Assignee: dveditz → bienvenu
Component: Security → Security: S/MIME
Product: Thunderbird → Core
Version: unspecified → Trunk
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.
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 Bob@siemens.com" and it gets back a cert and then uses it for encryption without verifying that the certified subject name contains Bob@siemens.com, 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.
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/
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
Component: Security: S/MIME → Security: S/MIME
Product: Core → MailNews Core
QA Contact: thunderbird → s.mime
You need to log in before you can comment on or make changes to this bug.