414563 - Chain validated with out-of-date CRL (PKITS tests 4.4.11, 4.4.12)

Status: NEW

(NSS :: Libraries, defect, P5)

Description

[Slavomir Katuscak]

PKITS tests 4.4.11 (Invalid Old CRL nextUpdate) and 4.4.12 (Invalid pre2000 CRL nextUpdate) fails for NSS.

In intermediate CA's CRL is nextUpdate set to the past, indicating that CA has already issuad updated revocation information. Chain is validated also with this out-of-date CRL.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

The relevant standards do NOT define a CRL's nextUpdate field as an expiration
date for the CRL.  Despite that fact, NIST has a policy that requires the 
CRL's nextUpdate field to be treated as a CRL expiration date, and their test suite tests for conformance with NIST's policy.

Note that NSS explicitly chooses not to interpret the CRL's nextUpdate field
as an expiration date for the CRL.  So this NIST test failure is deliberate.

We could resolve this bug as INVALID or WONTFIX.  However, the new cert path 
validation function CERT_PKIXVerifyCert is defined such that it can be 
instructed to enforce NIST's revocation policy.  I don't know if that feature
is implemented at this time or not.  Once it is implemented, this bug could
become an RFE to have vfychain set that option in its calls to CERT_PKIXVerifyCert.

Comment 2

[Julien Pierre]

This cannot be resolved until vfychain supports using CERT_PKIXVerifyCert with
the NIST CRL policy. See bug 412468 .

Comment 3

[Nuno Ponte]

The use of the nextUpdate field of CRLs as a "validity date" has already been discussed on the PKIX forum. See http://www.imc.org/ietf-pkix/mail-archive/msg03166.html

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Unsetting target milestone in unresolved bugs whose targets have passed.

Comment 5

[Kai Engert (:KaiE:)]

Bugs that are currently assigned to Julien => assigning to nobody.
Search for 20100628-kaie-jp