672871 - CERT_PKIXVerifyCert: CERTValOutParam cert_po_usages not yet implemented

Status: NEW

(NSS :: Libraries, defect, P5)

Description

[Kai Engert (:KaiE:)]

Function CERT_PKIXVerifyCert is designed to enable the caller to obtain the list of valid usages for a cert.

This output is designed to be requested by adding a member of type cert_po_usages to the CERTValOutParam parameter.

The value must be returned inside the union structure as "value.scalar.usages".

I searched nss/lib/libpkix for assignments to any variable named "usages", and I couldn't find any match.


It appears this feature has not yet been implemented.

Comment 1

[Kai Engert (:KaiE:)]

Where in the libpkix verification code should the code be added that loops through all usages, and tests them individually?

(similar to what happens in classic CERT_VerifyCertificate)

Comment 2

[Kai Engert (:KaiE:)]

... I suspect it should be added inside PKIX_PL_Cert_VerifyCertAndKeyType, but I don't know the code well enough to be sure.

Comment 3

[Kai Engert (:KaiE:)]

Attachment: Patch v1

This is a quick attempt to implement it.

I don't know if it's complete. I identified the places that need change by tracing, not through code review.

I don't know if PKIX_PL_NssContext is the right object to store the output usages. When I test this with PSM's "view cert" functionality, I get mixed results: In the first attempt to view a cert, the results seem to be correct, and multiple uses are displayed (and correct ones as it seems, based on root CA trust flags). However, In the second execution, only a single bit is shown. In the third execution it's complete again.

Comment 4

[Kai Engert (:KaiE:)]

The random behaviour is related to function PKIX_PL_Cert_VerifyCertAndKeyType and the arguments being passed to it during chain building.

PKIX_PL_Cert_VerifyCertAndKeyType has a parameter "isChainCert" which means "not a leaf cert".

During the chain processing, the function gets called twice.
Sometimes isChainCert is 0 both times.
Sometimes isChainCert is 0 once, and once has the value 1.
This causes the different results.

Does pkix chain building have a random component?

Comment 5

[Kai Engert (:KaiE:)]

After getting back to this bug, I'm starting to understand better.

My patch used a new attribute in the "NSS-Context" object used by libpkix. When checking for trust etc, the patch stores the results inside that context object.

That approach is too simplistic. When the trust checking functions get called multiple times, e.g. because multple certificates are being checked (the chain), then results can be overriden. I saw that the order to function calls (which certs checked first, etc.) can be different - that explains the random results I saw, because the results of the last funciton wins.

Assuming the general approach of this patch still makes sense:

- we need to remember the usages for which certificate are currently being queried
- when checking trust, inside the trust checking functions,
  only update the usages output parameter, if the currently processed cert
  is the certificate being requested by the original caller

Maybe the NSS-context is the wrong place to transport "usages for which cert are requested" and "result usages"?

Maybe the better place is the Processing-Params object?

If ProcParams should be used, then I'd have to pass it to additional functions. The functions currently checking trust don't receive it as a paramater.

Also, I suspect that member "PKIX_CertSelector *constraints" inside the ProcParams already contains information about the certificate being processed. But I don't understand yet how to use it.

I wish we had some documentation on the architecture of libPKIX and some documentation on the data flow of important objects. Reading the code is cumbersome.

Comment 6

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Is this an important feature? Perhaps we can just WONTFIX it?

I was able to implement this functionality on top of the existing libpkix code in Gecko by looping through all the usages we are interested in, independently validating the cert for each usage independently. This was not difficult to do. I would prefer to avoid adding more complexity to libpkix that adds functionality that can be done by the application without adding code to libpkix.