Non built-in OIDs display as Object Identifier (a b c) instead of something meaningful

RESOLVED WONTFIX

Status

Core Graveyard
Security: UI
--
enhancement
RESOLVED WONTFIX
7 years ago
a year ago

People

(Reporter: Sean Leonard, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12

Object identifiers are very useful for unambiguously identifying things, but few humans can look at one and instantly recognize them as something meaningful. PSM (in nsNSSCertHelper.cpp plus pipnss.properties) have two ways of finding associated localized strings that describe an OID. If the string is found, PSM uses that instead of displaying the OID. Otherwise, PSM generally shows
 Object Identifier (1 3 6 1 ...)

which is fine.

However, it would be nice if there was a way to extend the Certificate Viewer display (and other places) so that it could at least recognize other OIDs and display localized values. Other crypto stacks, namely the MS CryptoAPI, have provided this feature for years. Let's add it to NSS/PSM!

Reproducible: Always

Steps to Reproduce:
1. Obtain a certificate with custom extensions or custom EKUs.
2. Look at it in the Certificate Viewer.

Actual Results:  
See something like
 Object Identifier (1 3 6 1 4 1 311 21 7)

Expected Results:  
See something like
 Certificate Template Information

Additional responses will suggest an easy solution.
(Reporter)

Comment 1

7 years ago
There are at least two places that eventually make their way to the Certificate Viewer: GetOIDText (nsNSSCertHelper.cpp#297) and ProcessExtKeyUsage (nsNSSCertHelper.cpp#206).

Let's look at GetOIDText. If the OID is built-in, such as SEC_OID_PKCS1_SHA1_WITH_RSA_ENCRYPTION, there is a big switch that provides a bundlekey that is used to look up the localized value in pipnss.properties.

But if that fails, the OID is formatted into a string and substituted into CertDefDumpOID.

My proposal is that between these two points, the code calls some extensibility mechanism. Failing that, if the underlying OS has an OID lookup facility, the OS should be consulted (it can be consulted dynamically with PR_LoadLibrary as you may find it offensive to statically link to an OS lib such as crypt32.dll). Finally if the OS fails, the OID is formatted with CertDefDumpOID.

In the MS CAPI world, the function CryptFindOIDInfo is used. http://msdn.microsoft.com/aa379938. That function takes the OID and returns a localized string in CRYPT_OID_INFO -> pwszName. The function looks in two places: in internal CryptoAPI resources based on the process and thread language-list, and in HKLM\Software\Microsoft\Cryptography\OID\Encoding Type 0\CryptDllFindOIDInfo\{OID}!{type}\Name. If the name is a raw string, that string is used. But if the name points to a localizable resource, the localized resource is loaded based on the locale (culture) information.

So, the extensibility mechanism in PSM can look like one of the following:
1) Use nsIObserverService. Basically notify observers that some event occurred, which can return data (for example, by using a custom nsISupports-derived object).

2) Use nsICategoryManager. The category entry would look something like this:
nsICategoryManager->addCategoryEntry(
 aCategory = "psm-oid-keys",
 aEntry = "1.3.6.1.4.1.311.21.7",
 aValue = "chrome://pkg/locale/custom.properties#OptionalKey",
 aPersist = PR_TRUE/PR_FALSE (up to extender),
 aReplace = PR_TRUE/PR_FALSE (up to extender));

aValue specifies where to look up the custom OID value. This is necessary because aValue is a string (char*), not an nsAString, so it can't hold Unicode values easily, and even if it could, the call itself would not change based on the locale.

The aValue is just an URI of where the properties file is. If #OptionalKey is given, that key is used for the lookup. If that key is not given, then some other appropriate default, namely "1.3.6.1.4.1.311.21.7" or "CertDump_1_3_6_1_4_1_311_21_7", can be used.

Then the code just performs that properties lookup. On failure, the code drops down to the platform-specific case, then the default case.

3) Use the nsIPrefService. Basically it's the same concept as nsICategoryManager, except that you use some well-known branch. With preferences, it is easier for users or sysadmins (as opposed to programmers/extensions developers) to edit the preferences directly.

4) Build some custom registration interfaces in PSM. Then other code that wants to register new OID strings calls that registration interface and adds them.


I think that this #2 is the best option, but welcome comment about it. In my view there are very few users who would bother to customize the OID display, and they are not allowed to override the default OIDs anyway. However, it may be desirable for custom deployments (such as in a large organizational setting) to be built with preferences that include the organization's internal OIDs.

Repeat the same scenario for ProcessExtKeyUsage.
This is not an NSS bug.  It's a UI issue.  NSS doesn't do UI.
Assignee: nobody → nobody
Component: Libraries → Security: UI
Product: NSS → Core
QA Contact: libraries → ui
(Reporter)

Comment 3

7 years ago
Ok.
Well, it can be considered Security: UI, or Security: PSM.
This is more appropriate for an add-on.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

a year ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.