Closed Bug 162753 Opened 22 years ago Closed 22 years ago

CRL object needs to change PKCS#11 object ID upon modification

Categories

(NSS :: Libraries, defect, P1)

Product:
NSS
Component:
Libraries
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: julien.pierre, Assigned: julien.pierre)

References

Details

When installing a new CRL into the certificate database (softoken), the object
ID of the new CRL is the same as object ID of the old one. The way the CRL cache
will check for an object modification is to first look up if it exists, and then
check for its subject. With the current implementation, both tests would pass.

The fix is to create a new object ID when the new CRL is installed. This way the
CRL cache will know to flush itself and try to fetch a new CRL.
Priority: -- → P1
Target Milestone: --- → 3.6
Version: 3.5 → 3.6
Blocks: 149854
Bob,

This needs to get resolved for in order for the CRL cache to be able to pick up
changes to the objects. I am planning on checking it in tomorrow.

Assigned the bug to Bob.
Assignee: wtc → relyea
Moved to NSS 3.7, priority P1.
Target Milestone: 3.6 → 3.7
Moved to target milestone 3.8 because the original
NSS 3.7 release has been renamed 3.8.
Target Milestone: 3.7 → 3.8
Taking bug.
Assignee: relyea → jpierre
The problem that prompted the creation of this defect report was resolved in NSS
3.6 . See bug 167649 . The workaround was for NSS to automatically invalidate
the CRL cache for a given CA when a CRL for that CA is imported to softoken.
I am marking this bug WONTFIX since it means we don't need to do this
complicated fix to softoken.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.