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.
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.
Sounds fine to me.
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.
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.
Since we fixed bug 164867, this one is now a wontfix.