Closed
Bug 94013
Opened 23 years ago
Closed 16 years ago
Trying to download expired/or not yet valid CRLs produces no message
Categories
(Core Graveyard :: Security: UI, defect, P3)
Core Graveyard
Security: UI
Tracking
(Not tracked)
RESOLVED
WONTFIX
Future
People
(Reporter: inactive-mailbox, Assigned: KaiE)
References
Details
(Whiteboard: [kerh-ehz])
Trying to download an expired Certificate Revocation List produces no message. It simply does not get imported. You can see this behaviour at http://www.kuix.de/ca/expired.php What is expected: An informational error message should be shown.
Comment 1•23 years ago
|
||
P3 t->2.1 Kai, let me know how hard this is to do.
Priority: -- → P3
Target Milestone: --- → 2.1
Version: unspecified → 2.1
Comment 3•23 years ago
|
||
Updating summary to include CRL's that are not yet valid.
Summary: Trying to download expired CRLs produces no message → Trying to download expired/or not yet valid CRLs produces no message
RFC 2459 (http://www.ietf.org/rfc/rfc2459.txt) defines two date fields for CRLs: thisUpdate: This field indicates the issue date of this CRL. nextUpdate: This field indicates the date by which the next CRL will be issued. The next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date. CAs SHOULD issue CRLs with a nextUpdate time equal to or later than all previous CRLs. As you can see, there is no such thing as a CRL "expiration" or one that is "not yet valid". It's legal for the relying party to continue to use a CRL after the nextUpdate time. For example, if you're on an airplane reading s/mime signed emails and it's past the nextUpdate time, the client software may choose to show emails as signed with no error or warning. Or it may decide to show you a warning. Or maybe it decides to say nothing if you are offline and it's only been 20 hours since nextUpdate. We have to figure out what the right general behavior is, and then provide a way for users and admins to tweak that behavior for their needs. So for this bug: It's perfectly legal to import a CRL after nextUpdate. The client should import the CRL, and should warn the user that it's past nextUpdate. If possible the client should help the user get a fresh copy, but that's extra credit. ;-)
Comment 6•23 years ago
|
||
One the issues with CRL handling in NSS is the thisUpdate and nextUpdate fields are treated as validity fields. The code validating this is in In OCSP the nextUpdate field is supposed to be treated as an 'expiration' time if it's given (it's an optional field). If we are sure what the spec says, we can remove the Expiration check for CRL's. The function everyone calls to check the expiration of CRL's is SEC_CheckCrlTimes() in mozilla/security/nss/lib/certdb/certdb.c. The three places it's called is cert_DBInsertCRL() in .../certdb/pcertdb.c (when inserting a new CRL into the database), SEC_CheckCRL() and SEC_CheckKRL() in .../certhigh/certvfy.c (when verifying that a particular certificate is not the the revocation list. In any case if this is the correct semantic (ignore lastUpdate and nextUpdate fields), we should create this as an NSS bug. Also I suggest we do not change the semantics of KRL's because they are Government issued key revocation lists issued by FORTEZZA and departments already depend on our semantics, and 2 they are only used by FORTEZZA clients. No one else ever sees them. bob
Comment 7•23 years ago
|
||
Move to future. Won't have time to fix these for 2.1
Target Milestone: 2.1 → Future
Comment 10•22 years ago
|
||
I agree with Bob's comment #5 . CRLs don't expire. This bug is mostly invalid. There are some situations when we may want to show a message, such as downloading a CRL that's older than the one that's already there in the client database. Currently we don't even verify the signature of the CRL before importing it, or the trust on the issuer CA cert. The reason is that we can't, as the CA certs needed may not be available to the client at the time the CRL is downloaded. This checking is done of course eventually, but not at import time. It is done at the time the CRL is actually used, when NSS does a cert verification, and more recently in the CRL cache. Current time is not taken into account during those checks. Only the time passed to the verification function is. If the CRL is older than that time, it is still valid and may still contain the cert, if it was revoked at a previous date. If the CRL is newer than the verification time, it still gets used, as the revocation may have been done retroactively (ie. revoked 5 days after an employee noticed his key was compromised, but with a revocation date of that compromise event).
Updated•22 years ago
|
QA Contact: junruh → bmartin
Assignee | ||
Updated•19 years ago
|
Whiteboard: [kerh-ehz]
Updated•18 years ago
|
QA Contact: bmartin → ui
Comment 11•16 years ago
|
||
Bug 98193 seems like a good bug for dealing w/ the problems relating w/ CRL nextUpdate. So I've pushed it to NSS. I hope people don't object terribly....
Comment 12•16 years ago
|
||
spoke with kaie, he says that the behavior of nss/psm has changed and CRLs are no longer treated as having expiration dates. WONTFIX
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•