Re: Why is the crlNumber an OCTET STRING?

Manger, James <[email protected]> writes:

>Presumably CRLNumber has the “20 octet” language merely for consistency with
>CertificateSerialNumber. They sound so similar: numbering CRLs vs numbering
>certs.

Just noticed that the RFC text kinda confirms this:

   As noted in Section 4.1.2.2, serial numbers can be expected to
   contain long integers.  Certificate users MUST be able to handle
   serialNumber values up to 20 octets in length.  Conforming CAs MUST
   NOT use serialNumber values longer than 20 octets.

   As noted in Section 5.2.3, CRL numbers can be expected to contain
   long integers.  CRL validators MUST be able to handle cRLNumber
   values up to 20 octets in length.  Conforming CRL issuers MUST NOT
   use cRLNumber values longer than 20 octets.

So it's a cut&paste of the text for certificate serial numbers, for which
there's a legitimate reason, the German tank problem, to not use actual serial
numbers.

>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

Or ISO 8601 dates stuffed into the "serial number" for the CRL.

That does actually point out another issue though:

   The CRL number is a non-critical CRL extension that conveys a
   monotonically increasing sequence number for a given CRL scope and
   CRL issuer.  This extension allows users to easily determine when a
   particular CRL supersedes another CRL.

Isn't that what the dates in the CRL are for?  The only argument I can see for
using crlNumber is if you're brave enough to risk using delta CRLs.

Peter.