197009 - Certificate with T61-labeled iso-8859-1 characters is not shown in Certificate Manager

Status: RESOLVED FIXED

(Core Graveyard :: Security: UI, defect)

Description

[Hans Schou]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020510
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020510

I have downloaded and installed a test certificate from
https://www.certifikat.dk/developer/storage/AaseAereloev.p12
which have the real name "Åse Æreløv". I also downloaded another one with only
ASCII characters from
https://www.certifikat.dk/developer/eksempler.html
Password is Test1234

When looking in "Certificate Manager" the certificate with the name "Åse Æreløv"
is not shown. Only the one with the name "Test Testesen" is shown.
http://www.sslug.dk/signatur/mozilla-da/mozilla-da-10.png

Both certificate does work so this is just a minor detail.



Reproducible: Always

Steps to Reproduce:
1. Download certificate https://www.certifikat.dk/developer/eksempler.html
2. Install with password: Test1234
3. Open "Certificate Manager"

Actual Results:  
I can not see the name "Åse Æreløv". The name is just blank.
http://www.sslug.dk/signatur/mozilla-da/mozilla-da-10.png

Expected Results:  
Show the name "Åse Æreløv"

Comment 1

[Jean-Marc Desperrier]

Confirming problem with 2003031108, changing Component.
I don't get the problem in the exact same form as the reporter.

The certificate is displayed with a name of "test" in the windows of Certificate
Manager. I have no idea where this "test" value can come from.
View of the certificate declares that the certificate has no CN.
In Details, the subject view does show the correct value for CN.

The CN is encoded in ISO-8859-1 with a TeletexString.

Comment 2

[Jean-Marc Desperrier]

Forgot to change owner/QA. 
This should go in the same category as other comparable bug like bug 185167, it
clearly seems it's the PSM that is wrong, not browser.

Comment 3

[Jean-Marc Desperrier]

Could it be that the problem is that PSM is actually expecting valid
TeletexString, and will not tolerate ISO-8859-1 instead ?

In view details, bug 185167 shows that the data is always displayed in
ISO-8859-1 whatever the encoding is.

RFC3280 deprecates issuing new certificate in TeletexString encoding and
recommends UTF8String instead. The confusion in many CA between the
TeletexString encoding and ISO-8859-1 is a strong reason for that.

But it also says that implementer should try to accept both conformant
TeletexString encoding and ISO-8859-1 encoding in TeletexString strings.

Comment 4

[Kai Engert [:KaiE:]]

Confirming bug.
The certificate itself appears to be good.
It looks like NSS is handling the certificate fine, since it displays correctly
in the detail view.

I think it is PSM who is not dealing with the non-ASCII fields correctly.

Comment 5

[Lars Termansen]

I am having problems with certificate names containing danish letters, זרו, in
certificate manager.

For me it seems certificate manager is unable to display and handle certificates
if danish letters are present in certificate names - instead is displayed a
blank name. However the certificates works fine and are handled correctly by
mozilla for authentication etc.

Managing certificates is not possible - especially backing up of such
certificates is impossible. A backup results in the following error:
Failed to create the PKCS #12 backup file for unknown reasons


The above mentioned certificate from
https://www.certifikat.dk/developer/eksempler.html has NOT a name with danish
letters. I am unable to supply a certificate with a name containing such letters
as certificate name.

Comment 6

[John G. Myers]

Taking.

Initial triage suggests this is probably an NSS bug, CC'ing Nelson. 
CERT_DecodeAVAValue() is probably returning the CN value encoded in ISO-8859-1,
when the API is defined to return strings encoded in UTF-8.  I see no code in
NSS for converting T61 strings (or iso-8859-1 labeled as T61 strings) into
UTF-8--it appears to incorrectly assume T61 strings already conform to UTF-8.

Will work to confirm or eliminate the above theory.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

John,  (Good to see you here again!)

I believe your hypothesis:
"[NSS] appears to incorrectly assume T61 strings already conform to UTF-8."
is correct.

Comment 8

[John G. Myers]

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

Comment 9

[John G. Myers]

This has been fixed on the NSS trunk.  NSS was released just this past week, so
it seems unlikely this will make it into Mozilla in time for Mozilla 1.7.

Comment 10

[John G. Myers]

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

Comment 11

[Jean-Marc Desperrier]

Fixed/verified with 2004020208 (Windows 2000)

Afer import, the danish characters can be seen in the "certificate name" row of
Certificate Manager. They also are visible in the "common name" in the
Certificate Viewer. They also can be seen in the tree view of the "Details" tab
of Certificate Viewer, as well as when clicking on Subject in the lower partof
this tab.

I'd request to include this bug, and related encoding bug in NSS 3.9.1, so that
they end up in 1.7.b

A Mozilla 1.7 final with fully working i18n in certificates would be a really
good thing.

Is there be any way to include this inside Moz 1.4.2 ? That could be good for
some large non-US users that have decided on 1.4 for their Mozilla deployment
(cf http://www.mozillazine.org/talkback.html?article=3694).

Comment 12

[John G. Myers]

This is not fixed as NSS 3.9.1 has neither been released nor incorporated into
Mozilla.

Comment 13

[Wan-Teh Chang]

If this PSM bug is solely caused by NSS bug 53133,
this bug is already fixed in current Mozilla builds
(2004-01-28 or later) because the fix for the NSS bug
has been in the NSS_CLIENT_TAG (the NSS tag used by the
Mozilla trunk) since 2004-01-28.

(See http://www.mozilla.org/projects/security/pki/nss/nss-client-tag.html
for recent changes to NSS_CLIENT_TAG.)