192679 - No Friendlyname for X509 Cert with Teletextstring in CN, can't set FriendlyName

Status: RESOLVED DUPLICATE of bug 197009

(Core Graveyard :: Security: UI, defect, P3)

Description

[goetz]

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

When you create a X509 certificate with a Teletextstring (not PrintableString)
in the CN, and install it in mozilla,
Mozilla assigns no name to the certificate / key pair.
Selecting the certificate/key pair for use fails and
exporting the certificate/key pair fails.

And there is no way to set / change the name of the certificate / key pair.


Reproducible: Always

Steps to Reproduce:
1. go to a certificate authority of you choice (eg. www.trustcenter.de)
2. request a demo certificate, including a special character in the CN (Name)
   (in my case: Götz Babin-Ebell)
3. the key pair will be generated.
4. you get an email confirming you email address, reply it.
5. after some time you will get an email with an URL where you can install
   you certificate in you browser, install it.
6. in Edit-> Preferences->Privacy & Security -> Certificates ->
   Manage Cerifiucates -> Your Certificates -> <Certificate> -> View
   the Common Name is listed as <Not Part Of Certificate>
7. A backup fails with "unknown reason" in
   Edit-> Preferences->Privacy & Security -> Certificates ->
   Manage Cerifiucates -> Your Certificates -> <Certificate> -> Backup 
8. If you select the certificate for signing / encrypting 
   in Mail -> Edit -> Mail & Newsgroups Account Settings -> <Account> ->
   Security 
   sending encrypted / signed emails fails.

Actual Results:  
No Signing / Use of certificate / key pair was possible.


Expected Results:  
Shown some name
or let user change the name of the certificate.


importing a certificate/key pair with PKCS#12 and a given friendlyname allows
usage of the key pair...

Comment 1

[Matthias Versen [:Matti]]

-> PSM

Comment 2

[John Unruh]

Confirming. Getting a cert as Götz Babin-Ebell does not show a common name in
the cert received. Getting a cert as Security Test does. It must be the umlaut.

Comment 3

[Kai Engert (:KaiE:)]

Is this a regression?

Comment 4

[John Unruh]

This may never have been tested. Netscape CMS 6.1 doesn't like umlauts. Using
the name Götz Babin-Ebell at https://pki.mcom.com:1025/ca/ I could not even
request a cert, until I changed Götz to Gotz.

When I went to www.trustcenter.de in Navigator 4.78, this sort of works, except
his name in the cert is changed to GÈotz instead of Götz.

Comment 5

[goetz]

The conversion from Götz to GÈotz is a result of the character coding:

In the certificate the name is coded as TeletexString (aka T61String)
And in T61String the umlaut ö is coded as Èo (don't ask me for details...).

A normal CN (without special characters) is coded as PrintableString
But since Umlauts are not vaild in PrintableString, T61String is used.

Possible, the CN is only accepted if it is coded as PrintableString ?


BTW: is there a way to export the key pair with a different program,
     so I could import the key pair with an acceptable friendly name ?

If you really want to hate the different character sets and codings,
read Peter Gutmanns guide to X509...
( http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt )

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Attachment: CA cert that demonstrates this problem

This attachment will download a new CA cert into your browser that demonstrates

the problem

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Attachment: Same demo ca cert, in base 64 encoded ASCII (plain text)

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

The "General" tab says 
    Common Name  <Not Part Of Certificate>
The "Details" tab shows the CN in the cert's subject just fine.

Does PSM use different NSS calls to obtain the CN on the General tab than 
it does on the Details tab?

Comment 9

[Terry Hayes]

See also bug 53133, which discusses support for T61 (Teletex) in the NSS 
library.  In that bug, I suggested supporting the existing practice of putting 
Latin-1 character sets in the T61 choice for directory strings, as well as 
full support for the T61 encoding.

This bug suggests supporting the T61 encoding.  However, I don't think this is 
worthwhile. The UTF8 alternative is a much better choice in the long term, and 
is required by the current IETF RFC by the end of this year.

Comment 10

[Terry Hayes]

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

Comment 11

[Stephane Saux]

I did some research on how we display the different tabs:

Yes, it appears that we use
Components.classes[nsASN1Tree].loadASN1Structure(cert.ASN1Structure) for the
general tab, whereas we use the X509Cert stuff for the details tab. Not sure how
that differs at the NSS level. I think the data is set in nsNSSASN1Object.cpp.
I see the following code:
printableItem->SetData((char *)data, len);
Then, in GetDisplayValue:
aDisplayValue = ToNewUnicode(mDisplayValue);

In the DER, is there a way to determine that what will be a string value will be
in  TeletexString?

Anyway, maybe it would be sufficient to use NS_ConvertUTF8toUCS2(mDisplayValue)

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Terry, if CAs are going to generate certs with T61 encoding, then I think
we need to handle them properly,  OTOH, I'm not sure this bug is an NSS bug.

Comment 13

[Jean-Marc Desperrier]

> The "General" tab says 
>    Common Name  <Not Part Of Certificate>
> The "Details" tab shows the CN in the cert's subject just fine.

There's a parallel bug somewhere when the certificate has content in unicode
(UTF-8/BMPstring) where the "General" tab is correct, and the "Details" tab is
wrong.

I've found bug 185167 about that, but I remember there's another bug on the
issue. Maybe some META bug about encoding issues in certs would be useful.

Anyway the problem is *not* that the "General" tab is using the wrong method and
"Detail" the right one. In fact, if we considered that the RFC 2459/3280 are
deprecating T61String in favor of UTF-8, the method used for the "General" tab
is nearer from being correct. 
In fact, it might perfectly correct, and instead the code from "Detail" wrong by
blindly assuming ISO-8859-1 encoding, and the problem here only coming from the
missing support for ISO-8859-1 data inside T61strings required in bug 53133.

Comment 14

[Stephane Saux]

The details tab assumes UTF8, which it converts to UCS2 for display in the UI.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

NSS contains functions that explicitly convert from whatever encoding is used
in the cert's DN to UTF8.  When PSM is using a value returned by such a function,
it is proper to assume that the result if UTF8.  But it is also possible to 
access the raw unconverted values in the NSS memory structures.  If PSM is doing
that, then it should not assume UTF8.  My guess is that one of these path
(general or detail) starts with a converted value and the other with the raw
value.  But that's just a guess.

Comment 16

[Stephane Saux]

Nelson.
That's exactly my analysis. The code that creates the display in the general
basically uses a string obtained from the parsing of the ASN1 in PSM.

Comment 17

[John G. Myers]

*** This bug has been marked as a duplicate of 197009 ***