135175 - wrong smart card certificate used to sign email

Status: RESOLVED DUPLICATE of bug 191303

(MailNews Core :: Security: S/MIME, defect, P1)

Description

[ptest4]

When using a Common Access Card (CAC)with three certificates stored on it,
signed email messages are always signed with a certificate that is not intended
for email signing, regardless of which certificate has been selected to sign emails.

There are three certificates on the card: KE, DS, ID.  Of the three, two of
them, the DS and ID, have a 'Key Usage' of Digital Signature and
Non-Repudiation.  However, only the DS certificate contains an email address.
The ID certificate is intended for things like web authentication.  

Even if the DS certificate is selected to sign email messages, the ID
certificate is always used.  This problem not only occurs with Mozilla 0.9.8,
but with Netscape 4.7x and 6.x as well.

Because of another problem with Mozilla 0.9.9 (bug 128409) in which smart card
certificates are not visible, I cannot be sure if this bug still exists in 0.9.9.

It is possible that the order in which the certificates are stored on the smart
card is relevant, and that whichever Digital Signature certificate is first on
the card will be used to sign email messages.

Comment 1

[John Unruh]

S/MIME

Comment 2

[Stephane Saux]

kai.

Bob Relyea:
The code uses the following to find the signing cert:
  cert = CERT_FindUserCertByUsage(CERT_GetDefaultCertDB(), asciiname, 
           certUsageEmailSigner, PR_TRUE, ctx);

I think that in a 3 cert CAC card, both the ID and DS certs have the same
nickname, they also have the sign key usage bit, but the extended key usage is
different (email, client).

Reporter, can you confirm?

Comment 3

[ptest4]

Yes.  From the Mozilla Certificate Manager, all 3 certificates have the same
name.   For the DS certificate, the purpose is "Sign".  For the ID certificate,
the purpose is "Client,Sign."

Comment 4

[Kai Lahmann (is there, where MNG is)]

can somebody reproduce this with a recent Mozilla version like 1.1beta?

Comment 5

[Larry Riffle]

I have a similar problem with 1.1 only using imported certificates. The latest
issued with DS is selected for email sig. the latest issued with KE is selcted
for email enc regardless of NS cert type and ext key usage.

See 170101

Comment 6

[Kai Engert [:KaiE:]]

Are all the certificates have the same subject?
As a result, do all certs have the same nickname?
Since S/Mime configuration only identifies certificates by type and nickname,
the cert selection in NSS has multiple choices and makes the wrong decision?

Comment 7

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 8

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 9

[Robert Relyea]

I'm going to reopen this and close it as a dup of 191303. The bugs appear to be
related, and the resolution for one should affect the resolution for the other.

Comment 10

[Robert Relyea]

resolving dup so that bug 191303 has a pointer back to this bug.

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