Right now if we receive CRL v2, NSS crashes. NSS should not crash when CRL v2 is received.
*** Bug 54271 has been marked as a duplicate of this bug. ***
Here is javi's description of this bug: DoD has requested that PSM be able to parse v2 CRLs. The client does not have to know how to process the advanced features of v2 CRLs, but the client should not crash. Currently PSM crashes because NSS can't parse v2 CRLs.
I am raising the priority of this bug to P1. We need to get this fixed on the version of NSS in PSM 1.4, as well as the NSS 3.2 branch and the trunk. Bob, is this easy to fix? We just need to make NSS not to crash when a v2 CRL is received.
It should be relatively easy if we have a V2 CRL with its associated CA we can test with. bob
OK, I got a CRL from Michael Brown. and PSM 2.0 has no problem parsing it. I went back and looked at the code, and the v2 parsing support for NSS seems to be in since March 2000, maybe even earlier. So I guess what I need is a sample of a V2 CRL that does crash PSM2.0. I'll attach the CRL that seems to be working. bob
OK, I spoke too soon. The v2 CRL does indeed crash PSM 2.0 on load. I had my helper apps messed up and IE was parsing the V2 CRL (sigh). If you click on the attachment under Communicator, the V2 CRL won't load. If you click under PSM 2.0, it crashes. I can run pp -i crl v22.crl just fine from the latest version of NSS. I'll try running some of the other tools on this as well. bob
Bob, is this fixed?
Hmmm... Well the mysterious crash has now disappeared. My guess is it was crashing in some higher level code in mozilla. NOTE: just like communicator, the CRL does not load because it has extensions we don't understand, which is currently expected behaviour. bob
When you click on the CRL url, Mozilla will download the CRL. Questions: What happens with the most recent builds during this download? What happens when the client tries to reference this CRL (e.g. when visiting an SSL site)? and most importantly... Does that differ from the customer's expected behavior? If so, how?
In Communicator: the load fails with an error. In Netscape 6: the load silently fails. The CRL is never loaded, so there is no viewing issues. The bug is that attempting to load the CRL actually crashed mozilla. If we want the load to succeed then that's a separate bug, which I can start working on if we think the client will pick up the change and it's higher priority then my 3.4 work (both of these seems probably but not given). The biggest difference here is the silent failure. We verified that NSS is returning an error, and it looks like PSM is returning an error to the next level up, but no one puts up an error dialog.
OK, I do have a fix for actually loading this v2 CRL. This v2 CRL claims to be V2 but has not critical extensions. Unfortunately we check to see if the CRL is a v2 CRL, and if it is, we try to enforce the rule that v2 CRL's must have at least one critical extension. This rule is a source of heavy debate in the standards committe, and I don't think we should be enforcing it on accepting CRL's.... especially since we don't understand any critical extentions. I have a fix checked into the NSS tip, mozilla/security/nss/lib/certdb/crl.c rev 1.3. Should we try to get this into the PSM branch? bob
Bob, could you attach your v2 CRL loading patch to this bug report? This is required for code review, for both Mozilla and NSS 3.3. This fix needs to go into Mozilla.
PSM no longer crashes with V2 certificates.
This fix is not in 3.2.2. It is in 3.3 and on the 3.2 branch. Since we are not planning to make any new 3.2.x releases, I am setting the target milestone to 3.3.