Re: Why is the crlNumber an OCTET STRING?

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?

/Stefan


On 2021-04-21 17:55, Russ Housley wrote:
> Peter:
>
>>> The CRL number is helpful in any situation where the CRL issuer produces CRLs
>>> with different scopes.
>> How would the crlNumber help there?  And in particular, since thisUpdate is a
>> monotonically increasing sequence number, why is there a need for a second
>> parallel monotonically increasing sequence number?  It looks like an easy way
>> to implement crlNumber is:
>>
>>  crlNumber := thisUpdate;
>>
>> Which, in effect, is what the 8601-based implementation that's causing the
>> problem is doing, it's literally just copying the value of thisUpdate into
>> crlNumber.
> This would work if and only if the CRL issuer is dealing with one scope.
>
> For example, if a CRL issuer has partitioned the certificate population into multiple distribution points, all of these CRLs might be updated at the same time, but they each need different CRL numbers.  This kind of partitioning is used to make sure that none of the CRLs becomes overly large, even if the entire certificate population that it covers is revoked.
>
> Russ
> _______________________________________________
> pkix mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pkix