[UE] Add warning/information to verf window when cert has no email attributes

VERIFIED WONTFIX

Status

MailNews Core
Security: S/MIME
P4
minor
VERIFIED WONTFIX
16 years ago
9 years ago

People

(Reporter: Charles Rosendahl, Assigned: Stephane Saux)

Tracking

1.0 Branch
Future
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
when a certificate used for signing has no email attributes (either in the DN or
subjectAltName), additional information should be presented to the reader
indicating that the message integrity is intact, but that the sender could not
be identified as the true owner of the certificate.
(Reporter)

Updated

16 years ago
Priority: -- → P4
Summary: Add warning/information to verf window when cert has no email attributes → [UE] Add warning/information to verf window when cert has no email attributes
(Assignee)

Updated

16 years ago
Target Milestone: --- → Future

Updated

16 years ago
Keywords: nsbeta1

Comment 1

16 years ago
What do you think about the following idea?

Instead of checking the email address, we could test for an exact match of
common name and sender's name - the name we display when reading a message.

I even if we should include that always in our "valid signature tests".

I.e. we currently do:
- if signature is bad, display "bad sig", stop
- if email address is present in cert but does not match sender nor reply to,
show "bad sig", stop
- display "good sig"


I suggest to do the following:
- if signature is bad, display "bad sig", stop
- if neither common name nor email address is listed in cert, display "bad sig",
stop
- if common name is listed in cert, compare with sender's name. Ignore case when
comparing. Strip off the email portion from the sender's name. Ignore trailing
or leading whitespace. If the result does not match the cert's common name,
display "bad sig", stop.
- if email address is present in cert but does not match sender nor reply to,
show "bad sig", stop
- display "good sig"


In the above situation, if neither common name nor email address are present,
we'd always display a bad signature.

If both are present, both need to match.

If only one attribute is present, that one needs to match.
(Reporter)

Comment 2

16 years ago
Sounds fine to me.
(Assignee)

Comment 3

16 years ago
cc thayes
I don't see a good reason to check the CN. Signatures in email should have an
email address.
The current behavior seems fine to me.
emails are unique, but CN are not.

Comment 4

16 years ago
I discussed with Stephane. The current behaviour is not ok. Currently, the user
will NOT notice that the signature cert lacks an email address attribute, and
not notice, that Mozilla mail will have ignored that fact and still displays a
valid signature (assuming the signature is ok otherwise).

See also bug 164867, which now suggests to change that behaviour.
Making this bug dependent on 164867, since that decision should be made first.

Implementing bug 164867 would make this bug 137649 obsolete.
Depends on: 164867

Comment 5

15 years ago
Since we fixed bug 164867, this one is now a wontfix.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Keywords: nsbeta1
Resolution: --- → WONTFIX
(Reporter)

Comment 6

15 years ago
verf'd
Status: RESOLVED → VERIFIED

Updated

13 years ago
Component: Security: S/MIME → Security: S/MIME
Product: PSM → Core

Updated

10 years ago
Version: psm2.3 → 1.0 Branch

Updated

9 years ago
Component: Security: S/MIME → Security: S/MIME
Product: Core → MailNews Core
QA Contact: carosendahl → s.mime
You need to log in before you can comment on or make changes to this bug.