72296 - pk12util -i should allow user to specify nickname

Status: NEW

(NSS :: Tools, enhancement, P2)

Description

[Julien Pierre]

When importing certs/keys into a token with pk12util, the nickname of the cert 
in the target token is hardcoded to the same name that it had in the token in 
which it was extracted.
Eg. I have a cert/key in my internal DB called "Server-Cert".
I import it to my ncipher token, it becomes "ncipher:Server-Cert".

I assume the original nickname gets stored inside the p12 file.
I'd like to be able to change it and import the cert as some other nickname - eg 
"Other-Cert". There doesn't seem to be a way to do that currently. So I was 
forced to delete my existing "ncipher:Server-Cert" certificate/key before I 
could import the p12 file into the token.

Comment 1

[Robert Relyea]

This is a feature request, and won't make it until 3.3

bob

Comment 2

[Wan-Teh Chang]

Confirmed the bug and assigned it to me as a place holder.

Comment 3

[Wan-Teh Chang]

Assigned the bug to Ian.

Comment 4

[Wan-Teh Chang]

Moving the target to NSS 3.4.  (NSS 3.3. is now JSS/NSS
integration only.)

Comment 5

[Wan-Teh Chang]

Changed the QA contact to Bishakha.

Comment 6

[Wan-Teh Chang]

Set target milestone to NSS 3.5.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

This change was also recently requested in the newsgroup.  It requires a 
change to the pk12 library function interfaces, or at least some new API
functions.  

The current API presumes that the "friendly name" stored in the PKCS12 file
will be used as the "nickname" (after being translated from UCS2), and 
calls a caller-supplied callback function ONLY when either
a) the PKCS12 file has no "friendly name" in it, or 
b) the "friendly name" is already in use as the nickname of a different 
   cert subject name.  
The callback function's arguments do not include anything that helps the 
callback to know WHICH cert in the PKCS12 file has the problem, nor 
WHAT "friendly name" value has caused the lib to call the callback function.
See how mozilla attempts to work around this limitation in
http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsPKCS12Blob.cpp#660

The p12 library needs a SERIOUS overhaul to correct numerous original 
implementation deficiencies, including (not limited to):
a) it returns SEC_ERROR_NO_MEMORY for nearly all errors, even though 
   most detected errors are NOT caused by memory allocation failures.  
   It should be changed to return the proper error codes.
b) it assumes that nicknames are ASCII in NSS, and must be converted 
   from ASCII to UTF8 or UCS2.  If anything, it should assume that the 
   string is already UTF8.
c) it has a LOT of badly named functions, examples include:
   - using the term "unicode" instead of "UCS2" or "UTF16".  
   - using the term "nickname" ambiguously, to describe both PKCS12's 
     "friendly name", and NSS's nickname, even though they are rather 
     different.
d) the callback API deficiencies described above.  

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Julien,  I have another question about this bug.  
Was it the case that both your new cert and your old one had the same
exact subject names?
If so, then you were effectively trying to give multiple nicknames to
the same subject name. 
I might work on this bug, but I wouldn't try to overcome that limitation.

Comment 9

[Julien Pierre]

Nelson,

The bug is quite old, and I don't remember if the certs had the same subjects or
not when I tried to import them to the hardware token.

I don't think that PKCS#11 hardware tokens enforce that all certs for a given
subject have the same nickname. I think only softoken does that.

So technically, even if the certs had the same subject, we might try to import
them with different nicknames on a token other than softoken.

I think the original problem I was complaining about in this bug 3 years ago is
that pk12util import always used the friendlyName inside the PKCS#12 file, if
one is present, and there is no way to override it from the 
command-line with -n .

I'm not sure if we really want to fix this. PKCS#12 files can contain many certs
- including many end-entity certs, and many CA or roots. So, it isn't clear
which cert within the PKCS#12 file the -n argument would apply to when
importing. The behavior I wanted was for the case where there is one end-entity
cert in the file, to override its friendly name.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Giving pk12util bugs to Neil