94013 - Trying to download expired/or not yet valid CRLs produces no message

Status: RESOLVED WONTFIX

(Core Graveyard :: Security: UI, defect, P3)

Description

[(Don't use, old account) - Kai Engert]

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

[Stephane Saux]

P3
t->2.1
Kai, let me know how hard this is to do.

Comment 2

[Stephane Saux]

*** Bug 94617 has been marked as a duplicate of this bug. ***

Comment 3

[Stephane Saux]

Updating summary to include CRL's that are not yet valid.

Comment 4

[(Don't use, old account) - Kai Engert]

*** Bug 95319 has been marked as a duplicate of this bug. ***

Comment 5

[Bob Lord]

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

[Robert Relyea]

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

[Stephane Saux]

Move to future. Won't have time to fix these for 2.1

Comment 8

[(Don't use, old account) - Kai Engert]

Changing my prefered e-mail address.

Comment 9

[John Unruh]

OS > all

Comment 10

[Julien Pierre]

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).

Comment 11

[timeless]

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

[timeless]

spoke with kaie, he says that the behavior of nss/psm has changed and CRLs are no longer treated as having expiration dates.

WONTFIX