Re: Why is the crlNumber an OCTET STRING?

"Dars, Mihran [VendorPass]" <[email protected]> Fri, 30 Apr 2021 17:02:20 +0000
Newsgroups gmane.ietf.x509
Message-ID <BYAPR01MB41014AA2930D9989FA1710E4B75E9@BYAPR01MB4101.prod.exchangelabs.com>
Tend to agree with Ernst, if a CRL is copied to an isolated site, then number seems a better option to determine the latest one.
/Mihran

-----Original Message-----
From: pkix <[email protected]> On Behalf Of Ernst G Giessmann
Sent: Thursday, April 22, 2021 09:58
To: [email protected]
Subject: [**EXTERNAL**] Re: [pkix] Why is the crlNumber an OCTET STRING?

Stefan,
nevertheless it could happen, that you got two different CRLs, e.g. from
two different CRL distribution points, both valid (current time inside
thisUpdate and NextUpdate). How you decide which is the "current"?
Comparing the corresponding thisUpdate information? And if they are the
same due to lousy accuracy?
If you always implemented it this way, then your implementations are
wrong. The correct check is comparing the CRL numbers.
Sorry.
/Ernst.

Am 2021-04-22 um 13:21 schrieb Peter Gutmann:
> Stefan Santesson <[email protected]> writes:
>
>> 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.
>
> Same here, could never figure out what the purpose of it was.  Russ' answer
> about partitioned CRLs makes sense, but I'd never even considered that
> because, like delta CRLs, I've never encountered anyone brave enough to want
> to see what clients do in response to seeing one.
>
>> 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.
>
> Yup.
>
>> So basically, I find this interesting intellectually, but in what practical
>> context does this matter?
>
> I've got a client who asked about it, and my response of "I have no idea what
> purpose these things serve" was possibly a bit underwhelming :-).
>
> Peter.
>
>
> _______________________________________________
> pkix mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pkix
>

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