Re: Why is the crlNumber an OCTET STRING?

RFC 3280, Section 5.2.3 says:

   The CRL number is a non-critical CRL extension which 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.  CRL numbers also support the
   identification of complementary complete CRLs and delta CRLs.  CRL
   issuers conforming to this profile MUST include this extension in all
   CRLs.

   If a CRL issuer generates delta CRLs in addition to complete CRLs for
   a given scope, the complete CRLs and delta CRLs MUST share one
   numbering sequence.  If a delta CRL and a complete CRL that cover the
   same scope are issued at the same time, they MUST have the same CRL
   number and provide the same revocation information.  That is, the
   combination of the delta CRL and an acceptable complete CRL MUST
   provide the same revocation information as the simultaneously issued
   complete CRL.

   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.
   That is, if the this update field (section 5.1.2.4) in the two CRLs
   are not identical, the CRL numbers MUST be different.

   Given the requirements above, CRL numbers can be expected to contain
   long integers.  CRL verifiers MUST be able to handle CRLNumber values
   up to 20 octets.  Conformant CRL issuers MUST NOT use CRLNumber
   values longer than 20 octets.

   id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

   CRLNumber ::= INTEGER (0..MAX)

I see nothing about an OCTET STRING ...

The Appendix B says:

   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.  Conformant CRL issuers MUST NOT
   use cRLNumber values longer than 20 octets.

This does bot say anything about OCTET STRING either.

Russ

> On Apr 20, 2021, at 5:20 PM, Peter Gutmann <[email protected]> wrote:
> 
> This came up recently in an implementation, the crlNumber, defined as "a
> monotonically increasing sequence number for a given CRL scope and CRL
> issuer", is defined in RFC 3280 (but not the original 2459) as "CRL numbers
> can be expected to contain long integers.  CRL verifiers MUST be able to
> handle CRLNumber values up to 20 octets", i.e. a SHA-1 hash disguised as an
> INTEGER.
> 
> So if it's a monotonically increasing sequence number, why is it also a SHA-1
> hash?  How can a CA issue several billion CRLs/delta CRLs to overflow an
> actual integer?
> 
> Peter.
> 
> 
> _______________________________________________
> pkix mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pkix