On Apr 15, 7:08 pm, Robert Relyea <rrel...@redhat.com> wrote: > On 04/14/2010 03:30 PM, huican wrote: > > > > > Hello Bob, > > > Thanks for your reply... > > I have more questions inline ;< > > > On Wed, Apr 14, 2010 at 5:15 PM, Robert Relyea <rrel...@redhat.com> > > wrote: > > >> On 04/14/2010 02:58 PM, huican wrote: > > >>> Hello, > > >>> I am new to NSS crypto, I just wonder whether there is any easy way to > >>> use my own crl_callback function for CRL check. > > >> No, there isn't a callback, there is a verify function that allows you > >> to control just about every possible semantic of revocation checking. In > >> that case you can turn off CRL checking all together, and do your CRL > >> check later by hand. > > > Could you please give me a little bit more details? I need to know > > what is that verify function name, (or which file in the source tree > > to check)? > > CERT_PKIXVerifyCert() See cert.h and certt.h.> How to turn off CRL checking > there? > > Revocation checking is controled by *paramsIn. There are a set of > revocation policies set by default. None of them turn off CRL checking > for CRLs already fetched and valid. You'll have to write your own > policy. I suggest modelling it after the predefined > CERT_GetClassicOCSPDisabledPolicy(). The Revocation policies are meant > to be as flexible as possible -- and since revocation itself is rather > complicated (and certainly the choices of semantics are fairly > complicated) the revocation policy structure is fairly complicated. The > idea is that you should probably use one of the predefined policies, but > we could build new policies pretty quickly if the need arose.> What is your > meaning of "do CRL check by hand"? > > I mean you would have to do the CRL check yourself since you are trying > to use a custom CRL or whatever. I still can't conceive of a case where > you would *not* want to validate against an existing valid CRL if it's > already available, but that is what you seem to be asking.
Hello Bob, Thank you for the reply. My case is that in our software suite, there is crl process running already, which provides an API for the CRL check. That one worked for openssl lib. I was seeking a way similar on NSS, e.g, to use my own crl_callback function for CRL check on NSS. That running CRL process pulls down (either periodically or other setup) the CRLs from the configed crl URLs. It doesn't save the CRL itself, but only CRL's Revoke_reason etc. So I have no way to get the CRL content from it. Also the design here is that I am not suppose to pull the CRLs by myself. Thanks -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
