251594 - Certificate from PKCS#12 file with colon in friendlyName not selectable for signing/encryption

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P2)

Description

[Kai Kramer]

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]

Attachment: Here is a pkcs12 file with friendlyName "test:PN". Password is "test".

Comment 2

[Kai Kramer]

Attachment: For comparison: Same certificate but friendlyName is "test" now.

Comment 3

[Kai Kramer]

Password for both softtokens is "test".

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

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)]

Neil, please implement the suggestion in comment 4 in the pkcs12 decoder.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

*** Bug 320934 has been marked as a duplicate of this bug. ***

Comment 7

[Julien Pierre]

Retargetting all P2s to 3.11.3 .

Comment 8

[Neil Williams]

(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)]

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)]

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]

(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]

(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)]

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]

Attachment: add internal token name when nickname contains ':'

Implemented the suggestion in comment 13.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

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]

Attachment: 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]

Attachment: 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]

Attachment: 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)]

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)]

Attachment: 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)]

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)]

Checking in pki3hack.c; new revision: 1.93; previous revision: 1.92