Closed Bug 298879 Opened 20 years ago Closed 18 years ago

CRL validation doesn't work

Categories

(NSS :: Libraries, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: milan, Unassigned)

Details

(Whiteboard: [kerh-brz])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

I am writing PKI based plugin for Firefox. When I call
CERT_VerifyCertificateNow() to verify chain and CRL of one revoked certificate
it doesn't report that certificate was revoked, but returns SECSuccess. Btw, I
have already imported CRL into Firefox keystore using NSS.

I've been talking to the guys from NSS and they told me that probably cert was
imported into keystore as "trusted". There should probably be dialog asking for
explicit trust during import process.

Reproducible: Always

Steps to Reproduce:
1. Import revoked cert into Personal store.
2. Try to check revocation (e.g. with CERT_VerifyCertificateNow()).

Actual Results:  
CERT_VerifyCertificateNow() returned SECSuccess.

Expected Results:  
CERT_VerifyCertificateNow() should return SEC_ERROR_REVOKED_CERTIFICATE.

Guys from NSS claim there is nothing wrong with NSS, but the problem is in PSM.
Can you point us to the bug/mail (if it was publicly discussed) where the NSS
guys said that?
Severity: blocker → major
Here it is:

http://archive.netbsd.se/?ml=mozilla-crypto&a=2005-06&t=1007951

I was very bussy with other stuff, so I'm a little late with answer. :(

I hope this bug will be fixed soon.
Whiteboard: [kerh-brz]
QA Contact: psm
Any problems with CRLs would be NSS issues, not PSM issues.  But ...
Assignee: kengert → nobody
Component: Security: PSM → Libraries
Product: Core → NSS
QA Contact: psm → libraries
Version: Trunk → unspecified
There is no reproducible test case here.  
There is only unconfirmed conjecture about the cert being marked trusted.  

Marking a cert as "trusted" is the ultimate override.  The user himself
marks the cert this way, and in doing so, he instructs NSS to always treat
this cert as valid, regardless of ANY other indications that it is invalid,
(with one exception, expiration date).  This is the means by which a user
makes a self-issued cert (that comes from no known CA) work.

If indeed the cert is question was marked as trusted by the user, then the
correct behavior of NSS is to honor the cert, regardless of all 
contraindications, BECAUSE THE USER TOLD NSS TO DO SO.  

Only if the cert is NOT marked as trusted could this alleged incident of 
ignoring a CRL's revocation be really a bug.  And we have no reproducible
test case of this.  On the other hand, we have extensive evidence that CRL
revocations ARE honored properly for untrusted certs.  So, I am resolving
this bug as "incomplete", until such time as a reproducible test case is 
submitted.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.