97406 - extend object ID to text mapping in GetOIDText

Status: RESOLVED FIXED

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

Description

[(Don't use, old account) - Kai Engert]

Function GetOIDText in nsNSSCertificate.cpp should be extended to include more
object identifiers. For example, no mapping for signature algorithm
SEC_OID_ANSIX9_DSA_SIGNATURE_WITH_SHA1_DIGEST is currently available.

Comment 1

[Stephane Saux]

-> over to kai

Comment 2

[(Don't use, old account) - Kai Engert]

Changing my prefered e-mail address.

Comment 3

[Stephane Saux]

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

Comment 4

[boris marechal]

Add more OID value please like OID value: 2.5.29.19 whom is in almost all CA
certificate

Comment 5

[John G. Myers]

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

Comment 6

[John G. Myers]

from bug 185177:

2 16 840 1 113730 1 8 is the Netscape cert policy URL extension.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

NSS has a very complete list of OIDs and strings for them, and has functions
ot access those.  Rather than duplicating that list, as GetOIDText does now,
only partially, I'd suggest using NSS's list.  Some will argue that the list will
not be localized that way.  But I think having the names in English is better
than having the names only in dotted decimal.  Agree?  Disagree?

Comment 8

[John G. Myers]

PSM uses a separate list in order for the names to be localizable.  I'd say
keeping the current set of names localizable is important, as is extending the
list of localizable names to include at least those names mentioned in this bug.

I could see having the fallback code query NSS for an English name, which it
could use in preference to the OID.  That would be a separate bug.

Comment 9

[John G. Myers]

Attachment: Extend set of recognized OIDs

Comment 10

[John G. Myers]

I would have also added 1.3.6.1.5.5.7.1.3 (used in one of the Danish test
certificates) but that OID isn't in the NSS secoid table.

Comment 11

[Kai Engert [:KaiE:]]

I'm fine with adding the handling of additional OIDs.

However, I feel unsure whether your string code is safe.
I fear the NS_LITERAL_STRING code is producing a temporary string object, with
.get() returning a reference to the temporary.
I fear at the time you are using the bundlekey variable, the temporary object
might have already been destroyed, and the bundlekey variable might point to
modified memory.

If I'm right, the solution for more elegant code is to make use of
NS_NAMED_LITERAL_STRING, which defines local variables that will remain alive
for the scope of the function.

Comment 12

[John G. Myers]

Attachment: Second try

Comment 13

[Kai Engert [:KaiE:]]

Comment on attachment 139998 [details] [diff] [review]
Second try

thanks, looks good
r=kaie

Comment 14

[(not reading, please use [e-mail] instead)]

Comment on attachment 139998 [details] [diff] [review]
Second try

sr=sspitzer

Comment 15

[John G. Myers]

Fix checked in.