Re: Why is the crlNumber an OCTET STRING?

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