Re: [pkix] Why is the crlNumber an OCTET STRING?

Paul Hoffman <> Tue, 20 April 2021 22:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1A283A1F5F for <>; Tue, 20 Apr 2021 15:14:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JnTuBdjyKdWA for <>; Tue, 20 Apr 2021 15:14:34 -0700 (PDT)
Received: from (Opus1.Proper.COM []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 625993A1F5E for <>; Tue, 20 Apr 2021 15:14:34 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 13KMElIn061727 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Apr 2021 15:14:48 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: "Paul Hoffman" <>
To: "Peter Gutmann" <>
Cc: "IETF PKIX" <>
Date: Tue, 20 Apr 2021 15:13:59 -0700
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: <>
Subject: Re: [pkix] Why is the crlNumber an OCTET STRING?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Apr 2021 22:14:39 -0000

Not only is it not an OCTET STRING, you chose to use RFC 3280 instead of 
RFC 5280. :-(

Having said that, the question is germane. I cannot see how:
    The CRL number is a non-critical CRL extension that conveys a
    monotonically increasing sequence number for a given CRL scope and
    CRL issuer.
    Given the requirements above, CRL numbers can be expected to contain
    long integers.  CRL verifiers MUST be able to handle CRLNumber 
    up to 20 octets.
can both be true. I think that "long integers" is correct for some value 
of "long", but "20 octets" is just silly. I don't mind saying that CRL 
verifiers must be able to handle silly values, but would prefer to not 
have said that.

--Paul Hoffman