NSS should support delta-CRLs.
"Future" target implies P4.
*** Bug 95498 has been marked as a duplicate of this bug. ***
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.
Created attachment 209266 [details] 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.
I have attached a HTML file that demonstrates the problem.
I think that attachment was attached to the wrong bug. This bug has nothing to do with printing.