Patrick wrote:
> OK thanks.
>
> I believe the OCSP function prototypes are defined in OCSP.h, correct? How
> stable is that code?
It's at least as stable as the rest of the cert code. The OCSP API's are
probably more stable then the CERT API's.
>
> Also if I understand your last point about using CRLs in NSS, if I have a CRL
> imported and then I fail (network is down or something) to get an updated CRL
> by the 'last update/next update' field, NSS will reject any user cert issued
> by that CRLs' CA? How does Communicator handle this problem?
Yes.
Badly. It allows you delete the CRL and then continue processing.
> I figured Communicator and other browser use CRLs successfully, do they not?
Not really. If they did microsoft would not have to deal with the hacks
and patches they have for the incorrect certificates issued by Verisign.
>
> I guess one way around this problem could be to delete the CRL from my cert DB
> if I fail to get an update?...
Yup.
>
> Also what other 'corner problems' are there with respect to CRL and NSS? I'm
> pretty set on using CRLs with NSS (OCSP later) at his point. However I may
> reconsider if there are too many of these 'corner problems'...
If we take care of the expiration problem, the other corner cases are:
1) There is not automatic fetching of CRLs.
2) NSS only supports simple v2 CRLs and does not understand or parse any
extensions.
3) CRL processing can lead to incorrect results when time shift. For
example, if you receive signed email from someone, then later their key
is compromised, that previously valid email will show up as invalid.
Likewise if you receive email from a compromised cert, and later the
certificate expires and is removed from later CRL lists, that email will
suddenly show up as valid.
Case 3 is the hardest to solve, but I'm not sure it's the most important.
>
>
> -- Patrick
>
> Bob Relyea wrote:
>
>
>>Patrick wrote:
>>
>>
>>>Hello,
>>>
>>>Is there a way to use an OCSP responder with NSS so that NSS uses it
>>>when checking a certificate? I believe NSS would if the certificate had
>>>the OCSP info in it but I'm talking about configuring NSS to use a
>>>custom or local OCSP server...
>>>
>>Yes. There are three modes for NSS with respect to OCSP:
>>
>> 1) OCSP checking off. OCSP extensions are ignored, certs are processed
>>without revocation checking.
>> 2) OCSP checking on. If the cert has the OCSP extension, the responder
>>specified in the extension is checked.
>> 3) Default OCSP responder set. All certs are sent to the default OCSP
>>responder, which will comment on the revocation.
>>
>>I believe mode 3 is the mode you are looking for.
>>
>>
>>>Also can I get confirmation that in order for NSS to use a CRL, this CRL
>>>needs to be imported in the cert7.db beforehand. In order words, NSS
>>>does do any automatic CRL check over the net but strictly checks CRLs
>>>that are its certificate store.
>>>
>>NSS does not automatically fetch CRL's. Communicator has UI to help
>>fetch CRL's, and you can set up your company home pages to load CRLs
>>whenever they are referenced, but NSS never goes out and fetches CRLs.
>>
>>NOTE: NSS treats the 'last update/next update' fields in a CRL as
>>expiration fields. If you have a CRL loaded, and it's 'expired', NSS
>>will reject all certs cerified the the CA issuing that CRL. This is one
>>primary reason we discourage the use of NSS's built in CRL processing
>>(there a lot of little corner cases like this that would have to be
>>fixed for CRL's in NSS to be useful generally.
>>
>>bob
>>
>>
>>>-- Patrick
>>>
