351256 - Thunderbird doesn't find the right cert for signature

Status: NEW

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

Description

[Alaric]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060821 Firefox/2.0b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060821 Firefox/2.0b2

if there are 2 certs with the same private key for 2 email addresses, thunderbird may sign with the wrong one. This probablem also manifests itself in 1.5.0.X



Reproducible: Always

Steps to Reproduce:
1. Get 2 x.509 certs for 2 email addresses using the same private key, from the same CA or just use self-signed certs.
2. Set up the 2 accounts in thunderbird, setting the default signing cert to be the appropriate cert
3. send a test email from each account

one of the emails will have the wrong signing cert

Comment 1

[Alaric]

Apparently the reason for this is the way Thunderbird tries to uniquely identify a cert by combining the Security Device, Subject, and CA.  I am guessing that inclusion of the certificates Serial number should fix this problem. 

Comment 2

[Alaric]

Attachment: list of certs that firefox 2/thunderbird 2 sees

Comment 3

[Alaric]

Attachment: certs that are actually on the smartcard

Comment 4

[Alaric]

I have now replicated this bug with certificates that only have the same Subject from the same CA.

Comment 5

[Kai Engert [:KaiE:]]

Our current implementation selects the cert based on the cert's subject only.

Comment 6

[Alaric]

ok, first, thanks for actually looking at and responding to the bug. Now...


1. it's still messing up, it doesn't SEE the other certificates, the other certs don't even show up in the dropdown, even after adding the appropriate ICA.
2. It should be differentiating them based on serial number as well.
3. Neither firefox nor thunderbird correctly find the intermediate authority for a CA.  This might be listed as a bug somewhere else.

Comment 7

[Eddy Nigg (StartCom)]

(In reply to comment #5)
> Our current implementation selects the cert based on the cert's subject only.
> 

I don't think that this is the case. I suspect that it looks only at the public key (didn't checked the source so...). It should however look at different details as well, such as subject, serial and issuer - so to differentiate if one certificate uses the same private key. This entry should be confirmed as a bug.

Comment 8

[Kai Engert [:KaiE:]]

(In reply to comment #7)
> I don't think that this is the case. I suspect that it looks only at the public
> key (didn't checked the source so...). It should however look at different
> details as well, such as subject, serial and issuer - so to differentiate if
> one certificate uses the same private key. This entry should be confirmed as a
> bug.

Well, the key that we store in the preferences file is just the subject. So any lookups in future sessions seem to be based on that.

Comment 9

[Kai Engert [:KaiE:]]

Confirming, this needs some investigation

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

PKCS#11 assigns an "ID" attribute (known as CKA_ID) to each object (each key 
or cert) on the token.  Objects of different types may have the same IDs.  
For example a public key object and a private key object that are a pair may 
have the same IDs (and typically do).  Similarly a cert object that has a 
public key that matches a public key object on the token may have the same 
ID as the ID of the public key object.  

Commonly, 3 objects will have the same ID on a token: the private key, the 
corresponding public key, and the corresponding certificate.  

Commonly, CKA_ID values are computed as functions of the public key value,
e.g. a hash of the RSA modulus, IIRC, although this is not required by the 
standard.

But two objects of the same type must not have the same CKA_ID values.  
What I'm reading here suggests to me that on this particular token, there 
are two certs with the same CKA_ID.  If that is so, then that is probably 
a bug in the PKCS#11 software provided by the vendor of the token.  

NSS doesn't often look up certs by their public key values, (in fact, I'm
not aware that it EVER does so), but IIRC, it often looks up certs by 
their CKA_IDs.  So, if two certs had the same CKA_ID, that might explain 
this.  In that case, the appearance that the problem is due to shared 
public key values is really due to the sharing of CKA_ID values, which 
happen to be derived from public key values.

Bob will correct me here if I'm misremembering.  :)

Comment 11

[Kai Engert [:KaiE:]]

reassign bug owner.
mass-update-kaie-20120918