Re: Why is the crlNumber an OCTET STRING?

Presumably CRLNumber has the “20 octet” language merely for consistency with CertificateSerialNumber. They sound so similar: numbering CRLs vs numbering certs.
Peter is right that it doesn’t actually make much sense as you can’t use hashes for CRL numbers given they need to be ordered.
Limiting CRL numbers to, say, [0, 2^63] could have been friendlier to devs. But it’s too late for that.

It is almost conceivable that a CA could hash the details of a CRL’s scope, then replace the least-significant, say, 64 bits with nano-seconds-since-1970 ; - )

--
James Manger


From: pkix <[email protected]> on behalf of Peter Gutmann <[email protected]>
Date: Wednesday, 21 April 2021 at 8:29 am
To: Russ Housley <[email protected]>
Cc: IETF PKIX <[email protected]>
Subject: Re: [pkix] Why is the crlNumber an OCTET STRING?
[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments.

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.

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

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