John Gardiner Myers wrote:
For reasons you mention, even checking against the latest currently available CRL is at most "best effort".

I fully concur this is only "best effort". This is BTW exactly what I wrote in my message.

But it's the level of "best effort" that *can* be achieved.
I don't get why you want to settle for a "best effort" that is lower than that.


I think that not doing that would be what law calls "gross negligence".

So nextUpdate is really a minimum for the amount of time one should use cached CRLs.

I can't follow your logic here.


How do you go from
"even checking against the latest currently available CRL is not perfect"
to
"So I don't need to do it, and worse solution are OK" ?

"Even if I wait until the traffic light is green for pedestrian, there might be a car that won't respect it, so I won't care and I'll cross at the red light" ?
Or more perverse : "Even if I wait until the traffic light is green for cars, there might be a pedestrian that won't respect it, so I won't care and I'll cross at the red light" ?


Do you think that kind of reasonning is correct ?

The maximum is a matter of local policy, based on a risk assessment.

There's always a risk assessment that can justify anything.


In 1998, when the french banks were distributing smard cards with a signature done with a 320 bit long RSA key, their risk assessment was that updating all the ATM would be extremly costly (that was very right), and that the obscurity of the system made the probability of someone discovering the key was weak and breaking it very low, so that there was no way this would cost as much as replacing all these ATM. They ended up being ridiculised, having in a hurry to costly extend the key length to a reasonnable value, and their format loosing ground in favor of the concurrent EMV card format.

Anyway, what you say does not even describe the current behavior of NSS.

Currently the defined maximum for NSS is *infinite*.
If there's any crl available for checking, however old, the check will *never* return crl outdated. This is not configurable.


This in my opinion makes the CRL checking in NSS ineffective.
When the NSS chech says "check OK", a user that wants to know if all CRL used in the check were really up to day, needs to reimplement almost the whole certificate chain verification to do that.


This was recognised as a problem in bugzilla.
And probably there's nobody available to correct that.
But I can't get the logic of saying "it's not a problem".
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto

Reply via email to