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)
NSS
Libraries
Tracking
(Not tracked)
RESOLVED
FIXED
3.12.3
People
(Reporter: alvolkov.bgs, Assigned: alvolkov.bgs)
Details
(Whiteboard: PKIX SUN_MUST_HAVE)
Attachments
(1 file)
1.71 KB,
patch
|
nelson
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Updated•17 years ago
|
Priority: -- → P2
Whiteboard: PKIX
Assignee | ||
Comment 1•17 years ago
|
||
Failure to verify a signature of one of the cert in the chain should also be reported back to caller.
Comment 2•17 years ago
|
||
Could you be more specific about exactly which libpkix function you intend to modify here ? Thanks.
Assignee | ||
Updated•17 years ago
|
Priority: P2 → P1
Updated•17 years ago
|
Assignee: nobody → alexei.volkov.bugs
Updated•17 years ago
|
Version: 3.12 → trunk
Assignee | ||
Updated•16 years ago
|
Target Milestone: 3.12 → 3.12.1
Assignee | ||
Updated•16 years ago
|
Target Milestone: 3.12.1 → 3.12.2
Assignee | ||
Updated•16 years ago
|
Whiteboard: PKIX → PKIX SUN_MUST_HAVE
Assignee | ||
Updated•16 years ago
|
Severity: normal → enhancement
Priority: P1 → P2
Comment 3•16 years ago
|
||
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
Assignee | ||
Comment 4•16 years ago
|
||
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.
Comment 5•16 years ago
|
||
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?
Assignee | ||
Comment 6•16 years ago
|
||
> 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.
Assignee | ||
Comment 7•16 years ago
|
||
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 8•16 years ago
|
||
Comment on attachment 350877 [details] [diff] [review] Patch v1 - return revocation status r=nelson
Attachment #350877 -
Flags: review?(nelson) → review+
Updated•15 years ago
|
Target Milestone: 3.12.2 → 3.12.3
Assignee | ||
Comment 9•15 years ago
|
||
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.
Description
•