Re: Why is the crlNumber an OCTET STRING?

Peter Gutmann <[email protected]> Tue, 20 Apr 2021 22:28:47 +0000
Newsgroups gmane.ietf.x509
Message-ID <[email protected]>
Russ Housley <[email protected]> writes:

>the text explains there are various ways that a CRL issuer can assign numbers
>for different scopes that can lead to larger values.

It doesn't really explain it, all it says is:

   If a CRL issuer generates two CRLs (two complete CRLs, two delta
   CRLs, or a complete CRL and a delta CRL) for the same scope at
   different times, the two CRLs MUST NOT have the same CRL number.

So CRL #1 has crlNumber 17, CRL #2 has crlNumber 18.  That's monotonically
increasing, and fits into a standard integer.

Paul Hoffman <[email protected]> writes:

>you chose to use RFC 3280 instead of RFC 5280. :-(

I used 3280 because that's where the requirement for 20-byte "integers" was
introduced, so I was wondering what caused it.  My guess, for lack of any
obvious reason, was that it was someone's hack/implementation bug that was
written into the spec, because I can't see any other reason for the
OCTET_STRING-as-INTEGER use.  You certainly can't monotonically increase a
counter to the point where it'd be necessary.

Peter.