403684 - Implement CERT_PKIXVerifyCert's input param cert_pi_revocationFlags

Status: RESOLVED DUPLICATE of bug 403680

(NSS :: Libraries, defect, P1)

Description

[Kai Engert (:KaiE:)]

When attempting to verify Paypal's cert for EV, I was calling PKIX_VerifyCert.

When requesting
  cvin[1].type = cert_pi_revocationFlags;
  cvin[1].value.scalar.ul = CERT_REV_FLAG_OCSP
                            | CERT_REV_FLAG_CRL;

the function fails.
No CRL is imported, but OCSP is enabled.

Needs investigation.
OCSP checking MUST work for EV.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Isn't this just another consequence of the NIST CRL policy being on by default?
If so, then it is a duplicate of bug 403680.

Comment 2

[Kai Engert (:KaiE:)]

(In reply to comment #1)
> Isn't this just another consequence of the NIST CRL policy being on by default?
> If so, then it is a duplicate of bug 403680.

No. I was running with the patch from bug 403680.

Even when I change the above flags to use:

  cvin[1].value.scalar.ul = CERT_REV_FLAG_OCSP;

I still get the same behavior (failure).

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Thanks for that important information!

Comment 4

[Kai Engert (:KaiE:)]

Ok, this was easy to analyze...

The interface for CERT_PKIXVerifyCert defines 10 possible input parameters
  (cert_pi_nbioContext, cert_pi_nbioAbort, cert_pi_certList, 
   cert_pi_policyOID, cert_pi_policyFlags, cert_pi_keyusage, 
   cert_pi_extendedKeyusage, cert_pi_date, cert_pi_revocationFlags, 
   cert_pi_certStores)

  
But as of today, the implementation is really incomplete.
It only implements cert_pi_policyOID and cert_pi_date.

As soon as it discovers an input param that is not yet implemented (like the desired cert_pi_revocationFlags), the function simply returns with a failure and error code SEC_ERROR_INVALID_ARGS (seen in cert_pkixSetParam).


I'm therefore changing this function to a request to implement input param cert_pi_revocationFlags.

Comment 5

[Kai Engert (:KaiE:)]

I think the right way to implement support for cert_pi_revocationFlags is to update the proc params. I see several functions whose names start with "PKIX_ProcessingParams_". While I see function that talk about CRL, none of them talks about OCSP.

$ grep -r ^PKIX_ProcessingParam mozilla/security/nss/lib/libpkix/include/pkix_params.h |egrep -i "rev|crl|ocsp"
PKIX_ProcessingParams_GetRevocationCheckers(
PKIX_ProcessingParams_SetRevocationCheckers(
PKIX_ProcessingParams_AddRevocationChecker(
PKIX_ProcessingParams_IsCRLRevocationCheckingEnabled(
PKIX_ProcessingParams_SetRevocationEnabled(
PKIX_ProcessingParams_IsNISTRevocationPolicyEnabled(
PKIX_ProcessingParams_SetNISTRevocationPolicyEnabled(


Is there a way to request OCSP checking using a flag in ProcParams?

Comment 6

[Robert Relyea]

taking...

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

I'm wondering why there is a separate bug for this one aspect of the API
defined in/for bug 294531.  Bug 294531 is a P1 Beta1 blocker, and it 
includes this feature.  Is this bug a duplicate of bug 294531?
Perhaps in our weekly status meetings we should actively track the status 
of bug 294531. (?)

Comment 8

[Kai Engert (:KaiE:)]

(In reply to comment #7)
> I'm wondering why there is a separate bug for this one aspect of the API
> defined in/for bug 294531.  Bug 294531 is a P1 Beta1 blocker, and it 
> includes this feature.  Is this bug a duplicate of bug 294531?
> Perhaps in our weekly status meetings we should actively track the status 
> of bug 294531. (?)

Is it realistic to expect that bug 294531 will get completely implemented, including support for all 8 currently missing feature flags?

If that sounds unlikely, I propose this separate bug and feature gets done first.

Comment 9

[Robert Relyea]

The patch to implement this is part of bug 403680, closing this as a dup of the bug.