Re: Why is the crlNumber an OCTET STRING?

In case of revocations, a new CRL is generally issued before
NextUpdate. Therefore it makes sense to regularly refresh the cache
entry regardless of the NextUpdate value, in order to limit (based on
local policy) the delay of noticing a new revocation. And then you
could conceivably compare the CRL number and abort the refresh if it's
still the same, as a performance optimization.

However, I would agree that comparing ThisUpdate makes more sense,
also because it's one of the first fields of a CRL and thus more
quickly accessible.

Niklas


On Wed 2021-04-21 at 22:18h, Stefan Santesson wrote on pkix:
>Yes, I understand the logic. I just say that as implementer I never
>found the reason to use this in practice.
>
>In practice I have a policy that test if my current cached CRL is valid
>to use. If yes, then I use it. if no, then I discard it and attempts to
>get a new CRL.
>
>The new CRL is treated the same way before being used.
>
>Perhaps my implementations are to simplistic, but I never found a
>compelling reason to check and compare CRL number.
>
>/Stefan
>
>On 2021-04-21 22:04, Russ Housley wrote:
>> Stefan:
>>> Isn't this one of all these PKI things that is a great intellectual
>>> debate to fill out your time, but lacks any kind of real implications?
>>>
>>> I have done quite some PKI validation implementations, but I have never
>>> found any reason yet to check the CRL number for any reason what so ever.
>>>
>>> When I do CRL checking, I download the current CRL, check that it is
>>> current and still valid, and has the intended scope.
>>>
>>> No more, and no less. CRL number is not part of that process.
>>>
>>> So basically, I find this interesting intellectually, but in what
>>> practical context does this matter?
>> If you cache CRLs to avoid fetching every time that you perform validation, then the CRL number is one way to determine whether the just fetched one is more "current" than the one in the cache.  Assuming the same scope, date works for this too as Peter pointed out.
>>
>> Russ
>
>_______________________________________________
>pkix mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/pkix