1.68 KB, application/octet-stream
1.66 KB, application/octet-stream
2.82 KB, application/x-x509-ca-cert
1.53 KB, patch
Neil Williams: review+
|Details | Diff | Splinter Review|
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".
Created attachment 153313 [details] Here is a pkcs12 file with friendlyName "test:PN". Password is "test".
Created attachment 153316 [details] For comparison: Same certificate but friendlyName is "test" now.
Password for both softtokens is "test".
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.
Neil, please implement the suggestion in comment 4 in the pkcs12 decoder.
*** Bug 320934 has been marked as a duplicate of this bug. ***
Retargetting all P2s to 3.11.3 .
(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
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"
(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.
(In reply to comment #10) Certutil doesn't warn about creating a cert with a colon in the nickname either.
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.
Created attachment 264556 [details] [diff] [review] add internal token name when nickname contains ':' Implemented the suggestion in comment 13.
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.
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
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)
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.
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.
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 on attachment 264712 [details] [diff] [review] patch v2 - fix another copy of this code Neil, please review.
Checking in pki3hack.c; new revision: 1.93; previous revision: 1.92