Closed Bug 394077 Opened 17 years ago Closed 15 years ago

libpkix need to return revocation status of a cert

Categories

(NSS :: Libraries, defect, P2)

Tracking

(Not tracked)

RESOLVED FIXED
3.12.3

People

(Reporter: alvolkov.bgs, Assigned: alvolkov.bgs)

Details

(Whiteboard: PKIX SUN_MUST_HAVE)

Attachments

(1 file)

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.
Priority: -- → P2
Whiteboard: PKIX
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.
Priority: P2 → P1
Assignee: nobody → alexei.volkov.bugs
Version: 3.12 → trunk
Target Milestone: 3.12 → 3.12.1
Target Milestone: 3.12.1 → 3.12.2
Whiteboard: PKIX → PKIX SUN_MUST_HAVE
Severity: normal → enhancement
Priority: P1 → P2
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.
Severity: enhancement → major
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.
Ones libpkix to nss error conversion is done, check NSS error code to see if chain building failed due to revoked certificate.
Attachment #350877 - Flags: review?(nelson)
Comment on attachment 350877 [details] [diff] [review]
Patch v1 - return revocation status

r=nelson
Attachment #350877 - Flags: review?(nelson) → review+
Target Milestone: 3.12.2 → 3.12.3
Patch is integrated.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.