142655 - Cerificate Nickname not displayed for Other People's certs in viewer

Status: VERIFIED FIXED

(NSS :: Libraries, defect)

Description

[Charles Rosendahl]

Updated info on the problem, where there is an empty space displayed, when
looking at the details of a certificate.

I said, it is because the nickname is empty. This was wrong.

I looked what code really produces that empty space.

PSM accesses the ASN 1 structure of the cert, and displays that. The string at
level 0 (zero) looks empty. Usually it seemed to contain the common name.

So with the tip of NSS, something inside the ASN 1 structure seems to have changed.


Bob Relyea wrote:
'Other people's Certs' have an implicit nickname of the email address. That's
what is usually displayed in the cert manager.

bob

Charles Rosendahl wrote:

I see that it is empty in both the trunk and the test builds for various
certificates.  Side note - viewing the cert through the signature icon in the
mail client displays the nickname.  Viewing it from within Cert Manager does not.


Bob Relyea wrote:

Wasn't it always empty?

Kai Engert wrote:

I see this problem, too.

It seems, with the tip of NSS, the nickname of other persons is now empty?

------------------------------------------------------------------------

Subject:
Re: Please help testing special Mozilla Trunk + NSS Trunk build
From:
[e-mail] (John Unruh)
Date:
Mon, 06 May 2002 10:58:34 -0700
To:
Kai Engert <[e-mail]>


There is a difference in the way Other People's certs are displayed. Screen
shots attached. 5-6 Trunk first, then the new NSS build.

Comment 1

[Charles Rosendahl]

Attachment: Trunk View

Comment 2

[Charles Rosendahl]

Attachment: NSS Tip view

Comment 3

[Robert Relyea]

Kai,

I need to know what NSS call is returning NULL in PSM to cause this misdisplay.
It's clear PSM is able to correctly read the common name. Is PSM trying to read
the nickname of the cert and place those in these fields?

bob

Comment 4

[Kai Engert [:KaiE:]]

Please note: If you wated to order the comments in the bug description by time,
they would appear in reverse order.

My latest statement was: the real cause seems to be the attributes of the ASN 1
structure are now different. The empty space is produced by the attribute at
level zero of the ASN structure.

I have to dig some more what the actual NSS call is.

Comment 5

[Robert Relyea]

I'm confused by two things: 1) we can obviously parse out the CN because we are
displaying the CN all over, it's only certain places where the CN is not being
displayed.

2) what ASN.1 stuff are you talking about? There's lots of ASN.1 in NSS. Are you
talking about changes to an ANS.1 template, bad returnes from using the ans.1
decoder on a particular DER field (and which field is failing)? What is the
actual NSS call or field you are referencing.

bob

Comment 6

[Kai Engert [:KaiE:]]

Bob, I can now clear the confusion.

I was assuming only NSS uses ASN.1 internally. I was assuming PSM only reads
ASN.1 structures, but never writes them.

I was wrong. PSM builds its own ASN.1 structure, and uses it as a data structure
to store the contents shown in a hierarchical UI widget.

What I saw was that the first element of a ASN.1 structure was empty. But that
structure came from PSM itself.

With that new knowledge I looked at the code that fills that data structure. The
function that produces the (now empty) string is nsNSSCertificate::GetWindowTitle.

This helper function tries to decide which string could be used as a title
string for the certificate. And here is our problem.

GetWindowTitle looks at attribute CERTCertificate->nickname.

With the old NSS, this variable contains NULL. That is what GetWindowTitle
checks for. It detects the NULL, and will instead use common name or subject name.

With NSS_TIP_20020503, nickname is no longer NULL, but it is the empty string.

GetWindowTitle does not check for the empty string, it only checks for NULL. It
allows the empty string and displays it, leading to the effect described in this
bug.

This leads me the question: Is this new behaviour in NSS expected?

Assuming this new behaviour is allowed, it means that PSM will have to be able
to deal correctly with zero length nicknames. If you agree, I will produce a
patch that changes PSM to test for both NULL and empty nicknames.

Comment 7

[Wan-Teh Chang]

Kai,

I think we should be compatible with the old NSS releases
and set nickname to NULL as opposed to an empty string.
Otherwise, other NSS clients may have to make the same
change to test for both NULL and empty nicknames.

Comment 8

[Robert Relyea]

I agree with Wan-Teh. It was not an intentional semantic change, and I think we
should preserve the old semantics. This does make me feel better, we didn't
break nicknames for peer certs, we just didn't have any.

Anyway know I know where to look to fix this. Thanks Kai.

bob

Comment 9

[Wan-Teh Chang]

Assigned the bug to Bob.

Comment 10

[Robert Relyea]

Attachment: When forcing nicknames, make sure that we force NULL nicknames to NULL, not ""

Ian, could you review this patch (in fill_CERTCertificateFields).

bob

Comment 11

[Ian McGreer]

Comment on attachment 82961 [details] [diff] [review]
When forcing nicknames, make sure that we force NULL nicknames to NULL, not ""

looks good.

Comment 12

[Robert Relyea]

patch checked in

Comment 13

[Wan-Teh Chang]

Set target milestone to NSS 3.5.

Comment 14

[John Unruh]

Verified with the 5/10 new NSS build.