Closed
Bug 164867
Opened 22 years ago
Closed 22 years ago
Change request: S/Mime messages signed by cert w/o email address should not validate
Categories
(MailNews Core :: Security: S/MIME, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
psm2.4
People
(Reporter: KaiE, Assigned: KaiE)
References
Details
Attachments
(2 files)
3.09 KB,
application/octet-stream
|
Details | |
1.28 KB,
patch
|
javi
:
review+
mscott
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
Current situation: - somebody uses a cert which does not list an email address - that person sends a signed message - the mail client will detect that no email address is contained in the signature cert - if the signature is ok, the mail client will not complain, and not inform the user about the inability to match certificate and displayed sender address Suggested new behaviour: - if the signature cert lacks an email address attribute, make the mail client complain and do not show a valid signature.
Comment 1•22 years ago
|
||
The client should not indicate that a signature is valid unless it can match the certificate used to sign to the sender of the message. Currently, the only way to do that is with an email address. I'm not sure what you mean by "complain" -- there should not be a dialog box or other extra UI. It will be enough to display an invalid signature, and describe the problem that was encountered on the security status display that the user can reach by clicking the security icons.
Comment 2•22 years ago
|
||
The s/mime spec does say that the email component of the subject name and in the alternate address attribute are optional (should vs. must). So even though we don't validate if the cert has a complete lack of email addresses, should we prevent their usage for signing/encryption as well on our side? I can see where if we allowed it, we might have problems trying to respond in an encrypted fashion using the cert without email addresses.
Comment 3•22 years ago
|
||
when the rfc says should, it means it's recommended but the app has a choice. Our choice will be to say that the signature doesn't not validate if the cert doesn't have an email address. Let's get this in soon.
Priority: -- → P1
Target Milestone: --- → 2.4
Assignee | ||
Comment 4•22 years ago
|
||
I believe Charles is refering to our own S/Mime spec. So we should probably update our spec.
Keywords: nsbeta1+
Comment 5•22 years ago
|
||
Terry, speak up if you disagree showing a broken signature icon when the email is missing from the certificate. This is the only way we have to warn the user that something is not quite normal. The user can make a decision whether to trust the signature by looking at the certificate.
Assignee | ||
Comment 6•22 years ago
|
||
This is a certificate without an email address you can use for testing this bug. After having imported the cert, go to the CA tab to trust the CA for email certs. Configure the imported cert as your S/Mime cert. Send yourself a signed email, receive it and click it. A valid signature icon will be displayed. When we have fixed this bug, a broken signature icon should be displayed instead.
Assignee | ||
Comment 7•22 years ago
|
||
Assignee | ||
Comment 8•22 years ago
|
||
Javi, can you please review? cc'ing Jean-Francois, since the change is to the S/Mime portion of MIME.
Comment 9•22 years ago
|
||
Comment on attachment 102970 [details] [diff] [review] Patch v1 r=javi
Attachment #102970 -
Flags: review+
Comment 10•22 years ago
|
||
Comment on attachment 102970 [details] [diff] [review] Patch v1 sr=mscott
Attachment #102970 -
Flags: superreview+
Comment 11•22 years ago
|
||
R=ducarroz
Comment 12•22 years ago
|
||
Comment on attachment 102970 [details] [diff] [review] Patch v1 a=asa for checkin to 1.2 (on behalf of drivers).
Attachment #102970 -
Flags: approval+
Assignee | ||
Comment 13•22 years ago
|
||
fixed on trunk
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 14•22 years ago
|
||
Verified - the signature no longer validates. However, the error message is still misleading. The error message refers to altered headers rather than a missing email address in the cert.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•