Closed Bug 414561 Opened 18 years ago Closed 18 years ago

Crlutil returns exit code 0 when adding wrong CRL (PKITS test 4.4.6)

Categories

(NSS :: Libraries, defect)

3.11.9
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: slavomir.katuscak+mozilla, Assigned: julien.pierre)

Details

PKITS test 4.4.6 (Invalid Wrong CRL) fails for NSS. Importing wrong certificate returns exit code 0 what means success, but CRL is not imported (can't see it in crlutil -L).
Slavo, There isn't enough information in this bug report. certutil does not verify certificates at the time of import. As long as the certificate is valid DER and all the command-line options are OK, the import should succeed. Is your failure importing the CRL rather than the certificate ? crlutil tries to verify the CRL at time of import, unless you specify the -B option to bypass the CA certificate check together with -I. Please add more details about what specifically failred.
I just corrected Summary field, this problem occured in crlutil, not certutil. From logfile: --- Test case Invalid Wrong CRL Test6 certutil -d /export/home/sven/nss/securitytip/mozilla/tests_results/security/solaris-devx.21/pkits/PKITSdb -A -t ",," -n WrongCRLCACert -i ../../../../PKITS_DATA/certs/WrongCRLCACert.crt crlutil -d /export/home/sven/nss/securitytip/mozilla/tests_results/security/solaris-devx.21/pkits/PKITSdb -I -i ../../../../PKITS_DATA/crls/WrongCRLCACRL.crl pkits.sh: #32: Invalid Wrong CRL Test6 (0) - FAILED pkits.sh ERROR: Invalid Wrong CRL Test6 failed 0 --- You can find more info in PKITS tests description and data here: http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html
Summary: Certutil returns exit code 0 when adding wrong CRL (PKITS test 4.4.6) → Crlutil returns exit code 0 when adding wrong CRL (PKITS test 4.4.6)
Slavo, I tried running the pkits.sh script to reproduce this issue. It appears that it reuses the same PKITSdb directory for each test. The same DB gets modified after each test. This makes it rather difficult to recreate the actual state of the DB at the beginning of test 4.4.6 . I would recommend that we start over with a fresh DB for each test. I read the description of this test from NIST and examined the data files. There are a couple issues in the way of NSS passing this test : 1) The files TrustAnchorRootCRL.crl and WrongCRLCACRL.crl are for the same issuer - the subject of the root CA. This means the root CA must be installed prior to importing WrongCRLCACRL.crl , or the CRL import will fail, unless -B is specified to bypass the signature check. Also, the softoken can only store one CRL at a time per subject. So, one CRL will override the other during the import. 2) Not only do the files TrustAnchorRootCRL.crl and WrongCRLCACRL.crl have the the same issuer - they are completely binary identical. This means the second import of the WrongCRLCACRL will succeed, but it will be a no-op - the existing CRL will be overwritten by an identical one. 3) The test depends on the ability of vfychain to enforce the NIST CRL policy - which says that we need to have a CRL for every cert in the chain . At this time, vfychain uses CERT_VerifyCertificate, which doesn't have the ability to enforce the NIST CRL policy. We need vfychain to be modified to use the new CERT_VerifyPKIXCert, and configure it to enforce the NIST CRL policy, to pass this test. I tried to pass the -p argument to vfychain to do that, but I got : [jp96085@monstre]/net/monstre/export/home/julien/nss/tip/mozilla/dist/SunOS5.10_i86pc_DBG.OBJ/bin 594 % ./vfychain -p -d . -u 4 /home/jp96085/nist_pkits/certs/InvalidWrongCRLTest6EE.crt /home/jp96085/nist_pkits/certs/WrongCRLCACert.crt Chain is good! Assertion failure: secmod_PrivateModuleCount == 0, at pk11util.c:120 Abort (core dumped) In other words, the NIST CRL policy was not enforced, and we got a reference leak. 4) The pkits.sh script tries to delete the CRL for WrongCACRLCert . But there is no such CRL - only the CRL for the root CA. The script should be modified not to attempt to do this.
To clarify the above comment, there is no bug in crlutil here. It is being told to import the root CA CRL a second time, and does it happily. This is why it returns 0. So, I'm marking this bug as invalid. Please use the rest of comment 3 to resolve the other issues you will face in completing the run of test 4.4.6 .
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
In this case we have there 2 issues: 1. Bug in pkits.sh script - we expect CRL import to fail 2. Bug in pkits.sh script - we are trying to import CRL with non existing name 3. We don't use NIST CRL policy. I think first 2 issues should be fixed within this bug (I can do this), for third there should be at least reported bug/RFE.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Slavo, none of the 3 issues you described in comment 5 match the subject of this bug. Bugs in pkits.sh are test bugs, not libraries bugs. This bug is (or was) about crlutil. Please do not morph this bug to have another subject, but instead file another bug. If there isn't already such a bug, then a tools RFE should be filed to enhance vfychain to optionally use the NIST CRL policy. Please check for an existing bug before attempting to file a new one.
Status: REOPENED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.