Re: Why is the crlNumber an OCTET STRING?

Niklas,

Thanks for refreshing my memory. Yes, that is actually the process I
follow. Including comparison of ThisUpdate.

I just clearly recalled that I never saw the need to compare CRLNumber.

But I guess that is not what this thread attempted to solve. Sorry for
the side-tracking.

/Stefan


On 2021-04-21 22:51, Niklas Matthies wrote:
> 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
>
> _______________________________________________
> pkix mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix