Jean-Marc, There's a verb missing from this next sentence you wrote, and understanding that sentence depends entirely on the missing verb. Please fill in the missing verb, here | vAs a general rule, it's a bad idea to something that was only reluctantly inserted as a may in a RFC.
Sorry about my bad typing. I didn't think it was hard to guess the verb is "do".
Anyway, I think the really justified part of my reasonning was the part below that sentence, and that this sentence was more or less a rant, so you could have just ignored it.
Why this rant ? Because it's not the first time I see a developper say "hey, I won't do what is recommended in the RFC, look ! There's a may that allows me to do otherwise" and it's more than a coincidence that everytime it's a bad idea to do it. My conclusion is that you should use the permittivity allowed by a RFC "may" only if you have very strong *local* motive to do it, and that a general use product should never do it.
I also intended to add more details in a follow-up message, but I had a Mozilla crash while that follow-up was waiting.
I don't know about other Mozilla user, but I can't help feeling that since Talkback builds are not available anymore, crash is slowly becoming more frequent in new builds.
The two scenario I described in the treatement of CRL can be called "best-effort" and "non-repudiation".
If you try to achieve "non-repudiation", you base your decision on revocation information that is more recent than the transaction. So you will have to wait at least until you have a fresher CRL available, and maybe an additional delay if you take into account the fact the user is usually allowed a given delay to report compromission to his CA.
This is similar to a check deposit at your bank, where the money will not be actually available until the bank has completed full verification with the bank on which the check is drawn, which takes several days.
If you respond on-line, you can not do that, and have to settle for "best-effort". But "best-effort" means you do the best that is possible under the circumstances, and that you get the freshest CRL you know exist.
And after nextUpdate, you know there exist a fresher CRL, so by not using it, you are not doing your "best-effort" to have up-to-date revocation information.
Of course maybe the download site is off, so it's not possible at all to get that newer CRL, so using the last available one is still "best-effort", but it's hard to archive the information proving that, and the CRL checking process might not have access to it at all.
So if you do CRL checking at all, there are good reasons to report this check as failed if you only have access to a CRL whose nextUpdate is in the past. Except of course if you have an date argument in the check that says "Check validity for *this* date" and the date predates the nextUpdate of the available CRL.
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
