(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #85126 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=85126 Imported into Bugzilla on 03/07/00 12:04) I think this is an RFE, but it's a really important one. I need the ability to encrypt a msg to someone with a cert which may or may not match the From line. Right communicator automatically picks the cert based on the From value. Since alot of people these days have mutiple email addresses and some even get modified as they pass through firewalls, having this one-to-one mapping is silly, not to mention unusable. I think there are two solutions for this. 1) autoselect the cert based on from line but have a "select cert" button in the security tab of the composer that allows the user to select a different cert. 2) allow the user to define a many-to-one mapping such that mutiple email addresses map to the same cert. ------- Additional Comments From repka 04/28/98 17:41 ------- Slightly modifying summary line; adding jsw to cc list, changing platform to All because the behavior is XP, and reassigning this to me, at least for the time being. Brian, I think that each place you say "the From line" you really meant "the To line". Correct? Jeff, I'd like to talk to you sometime about this requested behavior. I'm thinking that the solution is really for the cert itself to be clear about what email addresses it is valid for -- as this is required for decent behavior on the receiving end as well. (I know this issue has come up before, often, on that end because people get torqued about us not saying the signature is valid if the email address doesn't match.) If you have comments on this, please toss 'em in here... ------- Additional Comments From bhern 04/28/98 17:45 ------- Well, the TO line of the message I'm composing (as a reply) is generate from the FROM or REPLY-TO line of the message I'm replying to. Take your pick on which POV you want. The idea is that I receive a message from "email@example.com" and the cert I have for him says on "firstname.lastname@example.org". I want to ability to manually tell the client to use the "email@example.com" cert for both "firstname.lastname@example.org" and "email@example.com". You cannot rely on the cert issuer to put all of the correct email addresses in the cert itself. ------- Additional Comments From marek Mar-01-2000 17:00 ------- mass-changing all old Communicator and Communicator Pro bugs filed for Comm. and Nav. versions older than 4.5 to WONTFIX. If you feel this was done in error, please reopen and reassign hong for consideration in 4.7x (assuming that you have a reproducible test case -- if you don't please don't reopen until you have one)
Giving this bug new life again in bugzilla.
I'm assigning this bug to chrisk, though much of the problem is on the certificate-side. He can at least prod to get that fixed. It's a long-standing problem that we only map one email address to one cert, and there are resulting issues on both the sending and receiving side. bhern's request may not be provide as is, but things could certainly be better -- and even the S/MIME v3 specs, as well as other IETF discussions about the same thing, have ideas about what must be provided.
What is with the signature? In 5.0, I can have a lot of identities, each with their own email address, which is used for the from line I send out. I can select the identity to use in the composer. Can I have one cert per identity or at least per email address? Will it be automatically selected correctly? Unfortunately, I can't test it, as the source isn't released.
Since S/MIME doesn't work yet in 5.0, the issue of selecting the certificate based on the identity selected in composer isn't a problem. In the future, the identity selected should have a direct impact on the certificate that is selected, and probably even on the way that certificate processing is performed when selecting certificates for encryption. Imagine that may want to allow email certificates from only a single CA for business communication, but think public "class 1" certs are fine for private correspondance.
What Terry says is correct -- no S/MIME in 5.0 yet anyway. But I think both of you are talking about a different subject (and avery interesting one, btw!) -- you're talking about multiple certs, varying with use or identity. This bug is about a single cert for which multiple email addresses should be usable. In that case, we have problems both on the sending and on the receiving side. On sending, we give you no way to send to anything other than *one* email address. If there are two (or ten) email addresses that all would end up at the same place, we provide no way to deal with that. Certs can already contain multiple email addresses, and we don't let them all "work". Also, when we compare the From address on the receiving side, we don't compare it with all of those addresses in the cert. Since we require the From address to match, we must be at least that lenient in the comparison. Hope that helps to explain a little better.
The new owner of S/MIME in NSS is mcgreer.
Adding Lord and relyea to the CC list for this bug.
Here's what the S/MIME v3 spec says about email addresses in the email certs. My reading of this is 1) you can implement systems in which the email address is not in the certificate, but 2) the spec does not say how clients which do so are meant to interoperate. We should provide and proposal to the S/MIME working group once we have an idea on how this should work: 3. Using Distinguished Names for Internet Mail End-entity certificates MAY contain an Internet mail address as described in [RFC-822]. The address must be an "addr-spec" as defined in Section 6.1 of that specification. The email address SHOULD be in the subjectAltName extension, and SHOULD NOT be in the subject distinguished name. Receiving agents MUST recognize email addresses in the subjectAltName field. Receiving agents MUST recognize email addresses in the Distinguished Name field in the PKCS #9 emailAddress attribute. Sending agents SHOULD make the address in the From or Sender header in a mail message match an Internet mail address in the signer's certificate. Receiving agents MUST check that the address in the From or Sender header of a mail message matches an Internet mail address in the signer's certificate, if mail addresses are present in the certificate. A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details.
People have multiple certificates and multiple e-mail addresses. I need to be able to pick the certificate, independent of the e-mail address I am using for both me, the sender, and for the receiver also. But, the S/MIME is no longer working at all in the 01/07 win2k release. It is impossible to get the enscrpt or sign buttons to stick! Is there some secret to getting this to work?:
What counts here is the public key of the other party. Once I agree to trust a public key (which can only really be done using out-of-band information), the public key is the person's electronic identity. Thus, there is no reason to require this to be associated with a fixed e-mail address. Indeed, one can easily imagine using PKI in settings where there is no e-mail, so while the e-mail address can be a part of the CN, there should be no requirement that this e-mail address match that if the sender or the receiver. If I get a signed message from Joe at some strange address, I will trust it assuming that I have not heard that Joe's private key has been compromised.
Bug 50823, and some other associated bugs, solve this when the cert is using the alternative name extension to list all the address it's valid for. This is the clean, interoperable way of handling this situation. But Mozilla is not so intolerant about using it with certs that do not match the email. Mozilla does allow to send mail using a certificate that does not match the From address (bug 139637 requires to change that). Mozilla will display received mail with a question mark (and not the broken pen icon) when the only mismatch is the name. The one thing missing is that it's impossible to send an email using a cert that does not match the destination adress. The bug 200862 I just entered is an enhancement request that would solve that, and also enable to suppress the question mark in the above case, and with that done, everything requested in this bug would be possible.
If I understand correctly, this bug is fixed by bug 50823. I think 200862 is a separate bug, that does not block this one, I'm removing the dependency. Please comment if you disagree. Thanks.
*** This bug has been marked as a duplicate of 50823 ***