Closed Bug 357082 Opened 18 years ago Closed 17 years ago

Request ability to select specific certs from among those with the same subject name

Categories

(Core :: Security: PSM, enhancement)

1.8 Branch
enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 278689

People

(Reporter: michael, Assigned: KaiE)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060911 SUSE/1.5.0.7-1.5 Firefox/1.5.0.7
Build Identifier: 

I use Thunderbird and have two certificates with the same common name (my full name) but different e-mail addresses. When I import them, I can only see the first one in Thunderbird when I want to select an encryption/signing certificate. I digged into the code, and found the following source of the problem:

It happens in the file p12d.c, in the function sec_pkcs12_validate_cert_nickname. In the beginning there are two lines:

certNickname = sec_pkcs12_get_nickname_for_cert(cert, key, wincx);
existingDNNick = sec_pkcs12_get_existing_nick_for_dn(cert, wincx);

I don't know much about the NSS source code (yet) but I'm guessing that the first one extracts the nickname from the certificate database, whereas the second one extracts it directly from the certificate.

When I import the first certificate, certNickname is empty, whereas existingDNNick is set to the CN of the certificate. This causes the code  below this to just set the nickname from existingDNNick.

When I import the second certificate, both these values are set to the same value? Well, actually not the same, because here are some debug information that I printed out:

certNickname: t = 0, data = Michael +ÿstergaard Pedersen, len = 28
existingDNNick: t = 77548440, data = Michael +ÿstergaard Pedersen, len = 29

Notice that the lengths are different, possible due to the danish character I have in my middle name, and some encoding problems. The type for existingDNNick will have a new value for each run of the program.

Still if these two were actually equal, I am confused. Because now the program will compare these, and if equal it won't do anything (and I get two certificates with the same nickname), but I just imported another certificate so something should be done to avoid nickname conflicts.

I am happy to try various things to solve this, but  I would really appreciate if someone could point me closer to why this bug is happening, and especially tell me what the two functions 

sec_pkcs12_get_nickname_for_cert(cert, key, wincx);
sec_pkcs12_get_existing_nick_for_dn(cert, wincx);

actually do.

Reproducible: Always

Steps to Reproduce:
See description
Actual Results:  
See description

Expected Results:  
See description
By defiition, Nicknames are a 1:1 mapping to subject names. 
They were invented before subject alt names were invented.
Their definition is not going to change.  
But applications are not required to use them.

You apparently have two certificates with identical subject distinguished
names but differing subject alt names.   That's unusual, to say the least.
Am I right in guessing that you issued these yourself?  

The definition of nicknames need not be changed (and will not be).  
To accomodate that unusual situation, PSM would have to provide a cert 
selection means that did not rely on nicknames.  
So, I'll turn this into an RFE for PSM, but given the unusual nature of
this situation (I'll stop short of calling it non-standard), I doubt this
will be high priority.
Severity: normal → enhancement
Component: Libraries → Security: PSM
OS: Windows XP → All
Product: NSS → Core
Hardware: PC → All
Summary: Certificates are imported with the same nickname → Request ability to select specific certs from among those with the same subject name
Version: unspecified → 1.8 Branch
Actually you guessed wrong. The certificates are issued by the danish government for all citizens of Denmark. Since you can get more than one certificate if you have different e-mail addresses, your name will still be the same for both certificates. This is the case here.
Michael,

That is rather strange for the government to issue more than one cert to a citizen based on e-mail address. They should issue you a new cert with the multiple e-mail addresses in it as subjectaltnames instead, and revoke your old cert when you have change e-mail. That would make a lot more sense. But there are no specs that preclude what they are doing currently, unfortunately.
Thanks for your answers. At least I know a little better what is going on, but apparently there is no simple way to fix this.

I tried hacking pk12util so I could import certificates and specify the nickname myself, but when I import the second certificate, type a unique nickname (and I can actually see that it it calls sec_pkcs12_set_nickname with the correct nickname) the certificate is for some reason still stored in the database with the nickname of the existing certificate. So that idea got me nowhere.
In NSS's software PKCS#11 module, for each unique certificate subject name
there can be only one nickname.  You can't change that.  The solution is 
not to try to get multiple certs with the same subject names to have different
nicknames.  That isn't going to fly.   

In order to be able to select a particular cert from among several with the
same subject name, the cert selection must be done on some other basis than
nickname.  One possibility is to select on issuer name and serial number.
Assignee: nobody → kengert
QA Contact: libraries → psm
Is this a dupe of bug 278689?
But at least it's related.
Status: UNCONFIRMED → NEW
Ever confirmed: true
> Is this a dupe of bug 278689?
I think so.
(In reply to comment #7)
> > Is this a dupe of bug 278689?
> I think so.

ok
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.