30883 - cert and S/MIME code need to handle multiple email addresses

Status: RESOLVED DUPLICATE of bug 50823

(NSS :: Libraries, enhancement, P1)

Description

[bhern]

(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 "[e-mail]" and the cert I have
for him says on "[e-mail]". I want to ability to manually tell the client to
use the "[e-mail]" cert for both "[e-mail]" and "[e-mail]".

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)

Comment 1

[Lisa Repka]

Giving this bug new life again in bugzilla.

Comment 2

[Lisa Repka]

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.

Comment 3

[Ben Bucksch (:BenB)]

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.

Comment 4

[Terry Hayes]

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.

Comment 5

[Lisa Repka]

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.

Comment 6

[Wan-Teh Chang]

The new owner of S/MIME in NSS is mcgreer.

Comment 7

[Robert Relyea]

Adding Lord and relyea to the CC list for this bug.

Comment 8

[Robert Relyea]

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.

Comment 9

[James Rome]

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?:

Comment 10

[James Rome]

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.

Comment 11

[Jean-Marc Desperrier]

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.

Comment 12

[Kai Engert (:KaiE:)]

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.

Comment 13

[Kai Engert (:KaiE:)]

*** This bug has been marked as a duplicate of 50823 ***