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

Stefan Santesson <> Wed, 21 April 2021 19:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD4D23A3447 for <>; Wed, 21 Apr 2021 12:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ckNoFORfKNxa for <>; Wed, 21 Apr 2021 12:38:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D4CCE3A343C for <>; Wed, 21 Apr 2021 12:38:26 -0700 (PDT)
Received: from (localhost []) by (Postfix) with UTF8SMTP id F0EE32E62293 for <>; Wed, 21 Apr 2021 21:38:21 +0200 (CEST)
Received: from (unknown []) by (Postfix) with UTF8SMTP id E18122E39198; Wed, 21 Apr 2021 21:38:21 +0200 (CEST)
Received: from (unknown []) by (Postfix) with UTF8SMTP id DE1281CE61CF; Wed, 21 Apr 2021 21:38:21 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10024) with UTF8LMTP id M4wZ_uOlrSNR; Wed, 21 Apr 2021 21:38:21 +0200 (CEST)
X-Loopia-Auth: user
Received: from [] (unknown []) (Authenticated sender: by (Postfix) with UTF8SMTPSA id 5172A1CE61CD; Wed, 21 Apr 2021 21:38:21 +0200 (CEST)
Message-ID: <>
Date: Wed, 21 Apr 2021 21:38:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:88.0) Gecko/20100101 Thunderbird/88.0
Content-Language: en-US
To: Russ Housley <>, Peter Gutmann <>
References: <> <> <> <> <> <> <> <> <> <>
From: Stefan Santesson <>
Organization: 3xA Security AB
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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: Wed, 21 Apr 2021 19:38:37 -0000

Isn't this one of all these PKI things that is a great intellectual
debate to fill out your time, but lacks any kind of real implications?

I have done quite some PKI validation implementations, but I have never
found any reason yet to check the CRL number for any reason what so ever.

When I do CRL checking, I download the current CRL, check that it is
current and still valid, and has the intended scope.

No more, and no less. CRL number is not part of that process.

So basically, I find this interesting intellectually, but in what
practical context does this matter?


On 2021-04-21 17:55, Russ Housley wrote:
> Peter:
>>> The CRL number is helpful in any situation where the CRL issuer produces CRLs
>>> with different scopes.
>> How would the crlNumber help there?  And in particular, since thisUpdate is a
>> monotonically increasing sequence number, why is there a need for a second
>> parallel monotonically increasing sequence number?  It looks like an easy way
>> to implement crlNumber is:
>>  crlNumber := thisUpdate;
>> Which, in effect, is what the 8601-based implementation that's causing the
>> problem is doing, it's literally just copying the value of thisUpdate into
>> crlNumber.
> This would work if and only if the CRL issuer is dealing with one scope.
> For example, if a CRL issuer has partitioned the certificate population into multiple distribution points, all of these CRLs might be updated at the same time, but they each need different CRL numbers.  This kind of partitioning is used to make sure that none of the CRLs becomes overly large, even if the entire certificate population that it covers is revoked.
> Russ
> _______________________________________________
> pkix mailing list