Last Comment Bug 251594 - Certificate from PKCS#12 file with colon in friendlyName not selectable for signing/encryption
: Certificate from PKCS#12 file with colon in friendlyName not selectable for s...
Status: RESOLVED FIXED
:
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: 3.4
: x86 Windows XP
: P2 normal (vote)
: 3.12
Assigned To: Nelson Bolyard (seldom reads bugmail)
:
Mentors:
: 320934 (view as bug list)
Depends on:
Blocks: 390184
  Show dependency treegraph
 
Reported: 2004-07-15 10:20 PDT by Kai Kramer
Modified: 2007-07-30 12:35 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Here is a pkcs12 file with friendlyName "test:PN". Password is "test". (1.59 KB, application/octet-stream)
2004-07-15 10:23 PDT, Kai Kramer
no flags Details
For comparison: Same certificate but friendlyName is "test" now. (1.58 KB, application/octet-stream)
2004-07-15 10:29 PDT, Kai Kramer
no flags Details
add internal token name when nickname contains ':' (912 bytes, patch)
2007-05-11 18:32 PDT, Neil Williams
no flags Details | Diff | Review
Updated test case with friendly name "test:PN", pw "test" (1.68 KB, application/octet-stream)
2007-05-13 05:46 PDT, Kai Kramer
no flags Details
Same certificate but friendly name is "test" now (1.66 KB, application/octet-stream)
2007-05-13 05:51 PDT, Kai Kramer
no flags Details
CA certificate for certificate from PKCS#12 files (2.82 KB, application/x-x509-ca-cert)
2007-05-13 05:59 PDT, Kai Kramer
no flags Details
patch v2 - fix another copy of this code (1.53 KB, patch)
2007-05-13 21:52 PDT, Nelson Bolyard (seldom reads bugmail)
neil.williams: review+
Details | Diff | Review

Description Kai Kramer 2004-07-15 10:20:46 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040210 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040714

If the friendlyName of an imported PKCS#12 file contains a colon (":"), it does
not appear in the select box of the "Select Certificate" dialog and can
therefore not be used for signing mails.


Reproducible: Always
Steps to Reproduce:
1. Import Certificate from a PKCS#12 file. The friendlyName must contain a colon.
2. Go to security settings for your mail account. 
3. Try to select the imported certificate for signing.


Actual Results:  
The previously imported certificate is not in the list of certificates. If there
are no other certificates, an error message occurs "Certificate Manager can't
locate a valid certificate that can be used to digitally sign your messages".
Comment 1 Kai Kramer 2004-07-15 10:23:40 PDT
Created attachment 153313 [details]
Here is a pkcs12 file with friendlyName "test:PN". Password is "test".
Comment 2 Kai Kramer 2004-07-15 10:29:16 PDT
Created attachment 153316 [details]
For comparison: Same certificate but friendlyName is "test" now.
Comment 3 Kai Kramer 2004-07-15 10:39:02 PDT
Password for both softtokens is "test".

Comment 4 Nelson Bolyard (seldom reads bugmail) 2004-07-19 12:32:19 PDT
NSS does not permit colon's in friendly names.  This is as designed.
The only "fix" that seems plausible is to change the colon character to
another character while importing. 
Comment 5 Nelson Bolyard (seldom reads bugmail) 2006-05-25 16:33:55 PDT
Neil, please implement the suggestion in comment 4 in the pkcs12 decoder.
Comment 6 Nelson Bolyard (seldom reads bugmail) 2006-05-25 17:00:50 PDT
*** Bug 320934 has been marked as a duplicate of this bug. ***
Comment 7 Julien Pierre 2006-06-20 16:30:30 PDT
Retargetting all P2s to 3.11.3 .
Comment 8 Neil Williams 2007-05-09 19:13:53 PDT
(In reply to comment #4)
> NSS does not permit colon's in friendly names.  This is as designed.
> The only "fix" that seems plausible is to change the colon character to
> another character while importing. 

Nelson, do you have a pointer to comments about this design decision? Some bugs claim that nicknames should be UTF-8, which would include ":".

I have just tried importing attachment 153313 [details] and it imports the cert without complaint.

bash-3.00$ certutil -L -d .
nick                                                         u,u,u
test:PN                                                      u,u,u
Comment 9 Nelson Bolyard (seldom reads bugmail) 2007-05-09 20:21:26 PDT
In nicknames, The colon character is a separator.  The general format is:

[<slot-name>:]<cert-friendly-name>  

When we parse a nickname, we look for a colon, and if found, treat the string
before it as a slot name (or token name, or both, I forget).  
You may be able to import it, but I'll bet you cannot list its contents with 
certutil -L -d. -n "test:PN"
Comment 10 Nelson Bolyard (seldom reads bugmail) 2007-05-09 20:28:19 PDT
Correction (to comment 9):  It's  [<token-name>:]<cert-friendly-name>

If you find, as I predicted, that the certutil command in comment 9 doesn't
work, then try this alternative:
   certutil -L -d. -n "NSS Certificate DB:test:PN"

That might work.  Let us know.
Comment 11 Neil Williams 2007-05-10 14:04:19 PDT
(In reply to comment #10)
> Correction (to comment 9):  It's  [<token-name>:]<cert-friendly-name>
> 
> If you find, as I predicted, that the certutil command in comment 9 doesn't
> work, then try this alternative:
>    certutil -L -d. -n "NSS Certificate DB:test:PN"
> 
> That might work.  Let us know.
> 

That works. Does that fact make this a non-problem? Perhaps a warning should be issued at import time.

Comment 12 Neil Williams 2007-05-10 14:19:56 PDT
(In reply to comment #10)

Certutil doesn't warn about creating a cert with a colon in the nickname either.

Comment 13 Nelson Bolyard (seldom reads bugmail) 2007-05-10 18:48:33 PDT
I'm not sure why this is an NSS bug, since it complains about a UI 
problem in ThunderBird or SeaMonkey.  I think this bug rightly belong
to PSM.  The question is: why doesn't the nickname appear in the list
of selectable nicknames?  

There is also an underlying issue with NSS, which may or may not be
the underlying cause of this bug.  I think we should fix the NSS issue
first.  That may solve the PSM problem too.  If not, then PSM work is 
needed to solve that issue.  

When NSS is asked for the nickname of a cert, NSS generally outputs the 
"simple nickname" if the cert is in the internal DB token, otherwise
it generally shows <token name>:<simple nickname>.  

On input, if the name contains one or more colons, NSS takes everything
up to the first colon as the token name, and everything after the colon
as a simple nickname.  If there is no colon, then the token name is 
implicitly "NSS Certificate DB", the name of the internal DB token.

When a simple nickname of a cert in the internal DB token contains a colon, 
it creates an ambiguity.  Does "test:PN" mean "a cert named PN in the test
token"? or does it mean "a cert named test:PN in the internal DB token?

I think the only solution to this problem will entail fixing a lot of
things in both PSM and NSS.   When NSS outputs a nickname, if it 
contains a colon, and it comes from the internal DB slot, I think NSS must
prepend the slot name explicitly, e.g. "NSS Certificate DB:test:PN".

Maybe, that change alone is sufficient.  Maybe that change alone would
make PSM begin to include the cert nickname in the drop-down list. 
Comment 14 Neil Williams 2007-05-11 18:32:44 PDT
Created attachment 264556 [details] [diff] [review]
add internal token name when nickname contains ':'

Implemented the suggestion in comment 13.
Comment 15 Nelson Bolyard (seldom reads bugmail) 2007-05-11 21:19:24 PDT
Neil, please create a new bug against NSS about the issue of displayed 
nicknames needing the token name when they contain a colon.  Then attach 
your patch (above) to that bug, and ask for review there.  I will give it 
r+ there.  

I now believe I erred when I confirmed this bug as an NSS bug.  
It should have been marked as a PSM bug, and probably was (is) invalid.
I will add more comments about that soon.

There are several problems with the cert in the attached P12 files.  

First:  It contains no email addresses at all, so PSM will NEVER find 
        it as being associated with ANY email account.  
Second: It is a (root) CA cert, not an EE cert.
Third:  It does not chain to a trusted CA, and is not explicitly trusted. 
Fourth: It is now expired.  (Although it was within its validity period 
        when the bug was reported.)

As a matter of policy, mozilla email clients require that a cert contain an
email address that matches the email address on the email account.  They 
won't let you use a cert with the wrong email address, or with NO email 
address, on an email account.  This policy has recently been reaffirmed.

So, AFAICT, the reason mozilla doesn't let the user select this cert for use 
with his email account has nothing to do with the presence or absence of a 
colon in the nickname, and has everything to do with the cert not apparently
being an EE email cert for any email address.  By mozilla's definition, 
the attached cert is not valid a email cert, and was not, even when it was 
within its validity period.  Even if that was not being enforced back in the
FF 0.8 days (when this bug was submitted), it is now.

If this claim (that PSM doesn't allow the selection of a cert just because
it has a colon in the nickname) could be demonstrated with a valid email
cert (one that has an email address in it, and that is not a self-signed 
CA cert, but rather is an EE cert), from a trusted issuer of email certs,
then I'd say we should pursue this further. But as a matter of policy,
the NSS team does not fix "bugs" that can only be reproduced with invalid 
certs.  

If the reporter wants to attach valid email certs that demonstrate the 
claimed bug, then perhaps this bug should receive further consideration.  
Otherwise, this bug should be resolved INVALID, IMO.

I am converting this into a PSM bug, since it was a complaint about 
mozilla client cert selection GUI, which is the domain of PSM.  
I recommend that if a valid test case is not produced, then this bug 
should be resolved invalid.
Comment 16 Kai Kramer 2007-05-13 05:46:12 PDT
Created attachment 264663 [details]
Updated test case with friendly name "test:PN", pw "test"

As requested an updated PKCS#12 file with an EE certificate with email address set
Comment 17 Kai Kramer 2007-05-13 05:51:02 PDT
Created attachment 264664 [details]
Same certificate but friendly name is "test" now

Updated PKCS#12 file. Same certificate as in attachment 264663 [details] but when imported from this file it is shown in certificate selection (email address does not seem to matter for selection)
Comment 18 Kai Kramer 2007-05-13 05:59:16 PDT
Created attachment 264667 [details]
CA certificate for certificate from PKCS#12 files

CA certificate for attachments 264663 and 264664. OpenSSL set basic constraint for CA to false, but it can be imported into Mozilla as an authority anyway.
Comment 19 Nelson Bolyard (seldom reads bugmail) 2007-05-13 21:47:25 PDT
Thanks very much for the certs.  I was able to reproduce the problem.
It seems that it IS an NSS problem after all.  
It requires a bigger patch than the previous one, but I have a patch now
that seems to fix it.  However, much more testing is required.
Comment 20 Nelson Bolyard (seldom reads bugmail) 2007-05-13 21:52:27 PDT
Created attachment 264712 [details] [diff] [review]
patch v2 - fix another copy of this code

The code that Neil patched appears in two separate functions in pki3hack.c
and both of them need to be patched.  The result of this patch is that the 
nickname in the CERTCertificate contains the token-name prefix, so that all
code that copies it from there will get the correct form of the nickname.
Comment 21 Nelson Bolyard (seldom reads bugmail) 2007-05-13 21:53:04 PDT
Comment on attachment 264712 [details] [diff] [review]
patch v2 - fix another copy of this code

Neil, please review.
Comment 22 Nelson Bolyard (seldom reads bugmail) 2007-07-13 23:01:22 PDT
Checking in pki3hack.c; new revision: 1.93; previous revision: 1.92

Note You need to log in before you can comment on or make changes to this bug.