(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #54965 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=54965 Imported into Bugzilla on 04/19/00 17:23) We can receive CRLs in signed S/MIME messages; we could also conceivably receive a "certs-only" attachment from a CA (or other place?) which is attempting to disseminate CRLs. Both of these cases should be doing something with the CRLs, I think. I believe Jeff thinks so, too. I will probably need to change the pkcs7 code somewhat to deal with this (unless Jeff does it himself like he did with importing certs ;-), but for now assigning this to Jeff because I do not think I have the interfaces necessary to deal with this in the first place. ------- Additional Comments From jsw 05/05/97 17:56 ------- VPs say this has to wait until the next release ------- Additional Comments From marek Apr-03-2000 18:08 ------- mass resolving LATER and REMIND bugs as WONTFIX (however, if you own one of these and have a fix that can be checked into 4.73 [assuming that you have QA lined up for it], please contact 4.73 project manager -- angelabu)

Old bug just moved from internal to bugzilla. Reopening so I can reassign it and comment on it.

This is a bug in NSS. I think both the cert code and the pkcs7 code need modifications to get it right. Reassigning to Christian to watch over the problem -- not sure who should own the cert-side of the problem, which is what needs to get worked out first so the pkcs7 code can then use it. There may even be two parts to it -- the dissemination of CRLs via a certs-only pkcs7 package (those would need to be stored) and the handling of included CRLs in a pkcs7 signature so that the CRLs are used during the signature verification (and whether or not they should *also* be saved locally, or maybe optionally this is done, then the issue is how that choice is made, etc.).

Set Target Milestone 4.0.

Assigned the bug to Bob.