Open
Bug 288237
Opened 19 years ago
Updated 2 years ago
Signing cert choice dialog does not warn if cert is not of this email address
Categories
(MailNews Core :: Security: S/MIME, defect)
Tracking
(Not tracked)
NEW
People
(Reporter: iang, Unassigned)
Details
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; FreeBSD) (KHTML, like Gecko) Build Identifier: version 1.0 (200050219) [FreeBSD ports build] In Edit/Account Settings/Security/Digital Signing/Select... dialogue I have available a CACert certificate for iang-iang-org. This is shown for both of my user accounts (iang-org and systemics-com). In both cases I can select the cert happily for signing. (I do not know whether the cert was added to both repositories or there is one shared repository.) In the case of systemics-com this results in warnings at a later stage as the signed emails are signed by the wrong key. It would be better if a warning were present at select time. (I'd prefer to still be able to sign with that cert, as most recipients know me as both and can deal with the issue... Still, this is a small point.) Reproducible: Always Steps to Reproduce: 1. Add cert for me@mine.org into account for myself@mycompany.com 2. Select cert 3. Sign next outgoing message. Actual Results: The recipient sees the message is signed with blue symbol /? which when clicked says "although the digital signature is valid, it is unknown whether sender and signer are the same person. ..." Expected Results: The receiving part is fine, although it would be nicer if it printed next to the "pen" icon the authenticated email address as certified in the cert. The sending software should probably warn on selection of that cert for signing with the wrong account that the email address doesn't match. I believe the user should still be able to go ahead.
Comment 1•19 years ago
|
||
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 2•19 years ago
|
||
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
Closed: 19 years ago
Resolution: --- → EXPIRED
Comment 3•18 years ago
|
||
I see this same behavior with trunk SeaMonkey, too, on WinXP. The UI will happily let me select a certificate for one of my numerous email accounts, even though that certificate does not bear the email address of that account. There is no indication of any kind that selecting this cert will cause recipients of my signed messages to get very questionable ("dodgy", to use Gerv's term) signatures. Perhaps this bug is in "core" code that is common to SeaMonkey and Thunderbird. Kai, do you know?
Status: RESOLVED → UNCONFIRMED
OS: FreeBSD → All
Resolution: EXPIRED → ---
Updated•18 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•18 years ago
|
||
Yes, this is handleded by PSM code that is identical for both SM and TB. When we implemented it, following the specs given at that time, we did not enforce an email address restriction. IMHO the default code should not require a manual cert selection at all, but we should automatically select a cert for the matching email address.
Comment 5•18 years ago
|
||
(In reply to comment #4) > IMHO the default code should not require a manual cert selection at all, but we > should automatically select a cert for the matching email address. What about the case where the user has more than one user cert with the same email address, issued by different CAs? (Bob Lord is one such user, IIRC). Surely such a user should have a choice about which cert is used.
Assignee: dveditz → kengert
Component: Security → Security: PSM
Product: Thunderbird → Core
QA Contact: thunderbird
Version: unspecified → 1.8 Branch
Comment 6•18 years ago
|
||
(In reply to comment #5) > > What about the case where the user has more than one user cert with the same > email address, issued by different CAs? (Bob Lord is one such user, IIRC). > Surely such a user should have a choice about which cert is used. My thinking is: - have a radio button in email security prefs - by default "choose cert based on email address" is selected - a secondary pref says "manual cert selection", and it contains the cert selection choices we offer today
Updated•17 years ago
|
QA Contact: psm
Component: Security: PSM → Security: S/MIME
Product: Core → MailNews Core
Updated•2 years ago
|
Severity: minor → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•