148214 - NSS should support delta-CRLs.

Status: NEW

(NSS :: Libraries, enhancement, P4)

Description

[Wan-Teh Chang]

NSS should support delta-CRLs.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

"Future" target implies P4.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

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

Comment 3

[Julien Pierre]

Implementing delta CRLs should be fairly straightforward, thanks to the CRL
cache changes made in bug 243585 . I would say that it is about 3 days, but
unfortunately the project isn't on my to-do list at Sun currently.

Nevertheless, here is what is left to do :

1) fix CERT_DecodeDERCrlWithFlags so that it supports delta CRLs .
There is currently a check for unsupported critical extensions which fails. We
would need to add the delta CRL extension to the supported list, and add a bit
in the opaque CRL fields to indicate that the CRL is a delta.

However, I think the deltas should only decode if a new flag is added,
CRL_DECODE_ALLOW_DELTAS . Otherwise, applications that until now were only
expecting full CRLs might get delta CRLs out of this function. The new flag is
needed to make sure the application can deal with a delta.

2) fix the new CERT_CacheCRL and CERT_UncacheCRL public functions so that they
use CRL_DECODE_ALLOW_DELTAS during the CRL decoding step

3) fix the CRL selection algorithm in DPCache_SelectCRL
Currently, the algorithm picks the CRL with the latest thisUpdate, and builds a
cache of it. The chosen full CRL is saved in the "selected" field of the DPCache
structure.

The new CRL selection function would need to find up to two objects instead of
one - a full CRL, as it does now, and a delta CRL which can be applied to it.

Identification of the best combination is probably better accomplished using the
CRL number extension (required by RFC 3280) than with the thisUpdate field.

Once the delta is identified (if any), then selectCRL would build a cache of the
delta, as it does now, with DPCache_Populate, which shouldn't need any modification.

4) Fix the DPCache_Lookup function, so that it does a look up of the serial
number in both the full CRL's hash table and the delta CRL's hash table, if
present .

This function would need to properly deal with the "hold" and "remove from CRL"
reason codes.

5) note that the above won't allow storage of delta CRLs in softoken, they will
only the CRL cache and thus the cert chain verification to process delta CRLs.
Adding delta CRL storage to softoken would require a new PKCS#11 object type to
be defined specifically for delta CRLs. This may require a new database format.
Part of the requirement would be the ability to store multiple delta CRLs. We
don't want to repeat the mistake of being able to store only one CRL per issuer.

However, adding PKCS#11 storage of delta CRLs is an optional part of the
project. Now that the CERT_CacheCRL / CERT_UncacheCRL APIs are available, NSS
applications have the ability to fetch CRLs on their own and feed them to the
CRL cache so NSS can use them, even if those CRLs can't be stored in a PKCS#11
token. Implementing steps 1 - 4 as described above would add the ability to feed
delta CRLs to those functions, instead of just full CRLs as is currently the case.

Comment 4

[David Lowrey]

Attachment: HTML that demonstrates the problem

This file demonstrates the problem.

The graphics representing the barcodes are missing, but that doesnt effect the problem.

It looks fine when you display it, but when you print it, it looks bad.

Comment 5

[David Lowrey]

I have attached a HTML file that demonstrates the problem.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

I think that attachment was attached to the wrong bug.
This bug has nothing to do with printing.