170101 - All personal certs with same key inherit nickname of the 1st imported.

Status: CLOSED INVALID

(Core Graveyard :: Security: UI, defect, P3)

Description

[Larry Riffle]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826

If I load multiple certs from multiple files created with "openssl pkcs12"
(0.9.6.g) the value of "-name" on the 1st import is inherited by those that
follow. If "-name" is not set the "imported certificate" is inherited even if
subsequent imports set "-name".

As a result the choice of email signing and encryption certs is limited to the
one with the latest date and keyUsage digitalSigning or keyEncipherment
respectively. If NS cert type and/or extended key usage don't support signing or
encryption cert it is still the only one that can be selected but won't work.

Same on linux RH7.3 w/openssl 0.9.6.d and 0.9.7 beta.

Reproducible: Always

Steps to Reproduce:
1.openssl pkcs12 -export -in cert1.pem -out cert1.p12 -name "cert one" -inkey my.key
2.openssl pkcs12 -export -in cert2.pem -out cert2.p12 -name "cert two" -inkey my.key
3.import cert1.p12
4.import cert2.p12

Actual Results:  
Both had nickname "cert one". If both had keyUsage digitalSignature then email
security would give only one choice for signing, the one with the latest issue
date. If you want to sign with cert2 you don't get a chance to select it.

Likewise for encryption if both had keyUsage keyEncipherment.

Expected Results:  
Assigned cert1 nickname "cert one" and cert2 nickname "cert two".

This can be a show stopper if, for example, the cert with the latest issue date
was intended for object signing only. It becomes the only selectable email
signing cert but won't work.

Work around is to make sure the latest certs are the right certs or use a
seperate key for each. In the 1st case issuing one new cert can mean reissuing
all old certs. In the second there are several more keys to either escrow or
risk users losing.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

All certs with the same Subject Distinguished Name will have the same 
nickname.  That's been part of NSS design from day 1.  It's not a bug.

If a cert is being selected that has improper usage extensions, that's 
a bug in the code that selected the cert.  It could be a bug in NSS, or
in the code that called NSS to pick the cert.  When there are a number
of certs with the same subject name and different usages, NSS should be
able to pick a cert with the right usage extensions to work for the 
purpose (e.g. email encryption) requested by the application.  

But the example shown above doesn't illustrate different cert usages 
(that I can see).  It illustrates trying to give two separate nicknames to
two certs with the same subject name, and NSS won't do that.

Unless some evidence of picking a cert with the wrong usages can be shown,
this bug is invalid, IMO.

Comment 2

[Larry Riffle]

If the same name issue isn't a bug it sure is an inconvenience here. We'd have
to find a way to insure that users with several special purpose certs make some
change in the DN. Since the DN may be auto-generated from LDAP I'm not sure how
we will do that. Could this be accepted as an enhancement? Is there some reason
a user shouldn't have multiple certs with the same DN for different purposes?

Mail does in fact choose certs invalid for the purpose. If, for example, on the
newest cert key usage includes digital signing, NS certype is SSL client and
extended key usage is client auth, only one cert will be selectable for email
signing but won't work. 

Comment 3

[Tim Church]

I have a perl script which uses certutil to generate a csr and then imports the 
request into a cert7.db, and then uses pk12util to export the cert to a p12 
file.  It does this twice for each user, once for a  signing cert, and once for 
an encryption cert.  I give each of these a  different nickname in the db.  The 
problem is this: upon importing both certs into another db, they end up with the
same name.  Order is not important, they both end up with the name of the first 
one to be imported.  This is on a Sun e10K under solaris 2.8.  The same setup on 
a Sun Ultra 5 does not have this problem, they both end up with the correct 
name.  Both machines have NSS3.4.1 and nspr 4.1.2  binaries loaded.  I tried 
using truss to follow the class, and the only differences I can find are some 
calls to open64 instead of open, and some libraries with different sizes. All
of these are in /usr/lib/64, which I have not overwritten anything from the 
original install.  

Comment 4

[Larry Riffle]

If one nickname per DN is set in stone then mail is going to have to select a
valid certificate since the user sometimes can't. Do I need to open a 2nd bug
against mail or can this one change component and Summary?

We're recommending mozilla to a lot of people. I need to get this resolved one
way or another.

Comment 5

[Stephane Saux]

The normal pki usage is to use the latest cert with a given nickname. This makes
sense and has worked well for years. It allows the pref set in Mail to still
work when the user updates the cert (because the old one is about to expire). He
gets a new cert, and it gets used automatically. If you had to actually specify
which of the certs with the same subject name/nickname to use, you'd have to
configure your client everytime you get a new cert with the same nickname.

Comment 6

[Larry Riffle]

I understand the last comment completely BUT mail can select an invalid cert and
the user can't do anything about it. If the user isn't going to allowed to
select from multiple certs with the same DN. ok fine. 

Mail is going to have to look at more than key usage to avoid selecting invalid
certs. See my several previous explanations. This is not theoretical. It is
happening to users here, now.

Comment 7

[Stephane Saux]

Please describe your PKI infrastructure deployment. It appears to be
non-standard enough that you're the only one having problems.
You should consider changing that deployment to use generally accepted practices.

Comment 8

[Stephane Saux]

In particular, if you need more than one cert per person (why?) that must be
valid at the same time with the same key constraints, then make sure that you
issue them with different subject names. For example:
user1 system1 client-auth
user1 system2 client-auth
user1 email signing.

Generally accapted practices would combine these three certs into one. A
certfificate is a proof of identity. Once identity is established, it's up to
applications to determine what priviledge a user should be granted.

Comment 9

[Larry Riffle]

I give up. We'll find another alternative.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Larry,  You've claimed that PSM chooses an invalid cert, but AFAICT, you 
haven't said what aspect of the chosen cert was invalid.  
Did it choose an invalid cert?  
Or did it merely choose one that was not the one you wanted it to choose?  
If the cert chosen was invalid, what aspect of the cert was invalid?

If NSS is choosing truly invalid certs, that's a bug and we should fix it.

OTOH, if you simply have numerous certs with identical subject names,
overlapping uses and overlapping validity periods, then you have another
problem.  

One idea that has been discussed from time to time is eliminating the 
nicknames, and letter users choose certs based on the entire subject name,
not just the "nickname".  But if, as I wondered above, you have multiple
certs with identical subject names, overlapping usages and validity periods,
then even choosing by subject name won't help you.  

Comment 11

[Larry Riffle]

Valid or not I see its fixed at or before 1.5.  At least you aren't forced to
use an invalid cert anymore thanks to unique nicknames.