The last parameter of cert_VerifyCertChain function is an address of boolean variable that, if passed, will tell to caller if a chain was not build due to revoked certs. Lib pkix currently returns PKIX_VerifyNode - a validation errors tree from which the revocation status can be obtained.
Failure to verify a signature of one of the cert in the chain should also be reported back to caller.
Could you be more specific about exactly which libpkix function you intend to modify here ? Thanks.
This is a binary compatibility requirement. If we're going to allow libPKIX to take the place of the old code, and be used through the old APIs, then it must still produce the right answers, or it is a regression. This cannot be SUN_MUST_HAVE and be P2.
The old code is checking the revocation status of the cert and if it is positive(cert is revoked) returns it to a caller. The libpkix algorithm is a bit different: we check revocation status of the cert and if the cert is revoked, we try another path to find out if there is a valid candidate cert that can be used to complete the chain. In this case would you agree with the following: If there is another candidate cert which lead as to completion of the chain to a trusted anchor, then we report success. If the use of the second cert didn't lead us to a trusted anchor and there is not other alternatives, we will report chain building failure due to revoked status of the cert.
Clearly, if we report success, we should not also report a revoked cert. I guess the question is: what happens if there are multiple paths, all of which fail for different reasons? If one path fails because a CA cert was revoked, and another path fails because (say) a CA cert is expired or has an unknown issuer, then what do we report about revocation status? In the end, we return a single error code. That error code comes from one of the certification paths. (I don't know which one. first? last? nastiest?) I think that the revocation boolean value should be for the same path whose error code is returned. Does that make sense?
> In the end, we return a single error code. That error code comes from one > of the certification paths. (I don't know which one. first? last? nastiest?) > I think that the revocation boolean value should be for the same path whose > error code is returned. Does that make sense? Today the final failure reported to a caller is the last failure that was received. I think your statement makes sense since a caller may request a log to be returned. Later the log can be parsed, if needed, to understand a particular reason for a CA cert rejection.
Created attachment 350877 [details] [diff] [review] Patch v1 - return revocation status Ones libpkix to nss error conversion is done, check NSS error code to see if chain building failed due to revoked certificate.
Comment on attachment 350877 [details] [diff] [review] Patch v1 - return revocation status r=nelson
Patch is integrated.