62266 - pk12util import fails when multiple certs for nickname

Status: NEW

(NSS :: Tools, defect, P3)

Description

[Ian McGreer]

I was able to create a p12 blob for a nickname that has multiple certs, but
attempting to import it failed.  Some certs were expired.  Nickname may have
also existed in database being imported to, so may not be a bug but just an
unclear error message.

Comment 1

[Wan-Teh Chang]

Changed the QA contact to Bishakha.

Comment 2

[Wan-Teh Chang]

Set target milestone to NSS 3.5.

Comment 3

[Wan-Teh Chang]

Moved to target milestone 3.8 because the original
NSS 3.7 release has been renamed 3.8.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Remove target milestone of 3.8, since these bugs didn't get into that release.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Ian, can you reproduce this? 
If so, can you attach the created .p12 file to this bug?
I am interested in improving pk12util's handling of nickname "collisions".
Without a copy of the .p12 file, it's difficult to know what's going on.

Comment 6

[Julien Pierre]

Attachment: a PKCS#12 file that contains two different certs with the same friendly name

I'm not sure if this is the same problem as originally reported, but it's close
enough. Currently, pk12util claims to accept this file when importing.
But actually the second cert does not import.

I would argue that this PKCS#12 file is bogus because the two certs have the
same friendlyName . However, strictly speaking, per the PKCS#12 spec, the
friendlyName is an optional component meant to be visually displayed, not a
unique identifier, so you might make a case (and the producer of this file has
argued!) that it is a valid PKCS@12 file. Other tools (IE, OpenSSL) don't
enforce the unicity requirement (let alone not to conflict with an existing
database nickname), so that makes NSS look bad.

Currently, when you import this file with the tip, pk12util claims success, but
it actually only imports the first cert (user cert), and the CA cert silently
fails to import. The failure to import is due to bug 202979, which I have
reopened.

We need to make a decision regarding this file. Either :

1) we regard it as an invalid file. We should detect the collision and report
the failure to import it (hopefully with some accurate error !!!)

2) we regard it as a valid file. In this case, we should detect the import
failure, and try to import again, perhaps with a made-up nickname, ignoring the
duplicate friendlyname in the file .