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)

1.8 Branch
x86
All
defect

Tracking

(Not tracked)

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.
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
Closed: 19 years ago
Resolution: --- → EXPIRED
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 → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
(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
(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
QA Contact: psm
reassign bug owner.
mass-update-kaie-20120918
Assignee: kaie → nobody
Component: Security: PSM → Security: S/MIME
Product: Core → MailNews Core
Severity: minor → S3
You need to log in before you can comment on or make changes to this bug.