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

Russ Housley <housley@vigilsec.com> Tue, 20 April 2021 21:41 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1A13A1D92 for <pkix@ietfa.amsl.com>; Tue, 20 Apr 2021 14:41:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8ucguSPbOxx for <pkix@ietfa.amsl.com>; Tue, 20 Apr 2021 14:41:43 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792B73A1D8F for <pkix@ietf.org>; Tue, 20 Apr 2021 14:41:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 097C6300BA6 for <pkix@ietf.org>; Tue, 20 Apr 2021 17:41:41 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Fbzpi4jJ8XGy for <pkix@ietf.org>; Tue, 20 Apr 2021 17:41:39 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 3B6F73000B9; Tue, 20 Apr 2021 17:41:39 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <3d6d5a6ea9ca4a6a99791da46435b7cf@uxcn13-tdc-d.UoA.auckland.ac.nz>
Date: Tue, 20 Apr 2021 17:41:40 -0400
Cc: IETF PKIX <pkix@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <490638C0-9D93-4998-9F5D-1C9804B8E95C@vigilsec.com>
References: <3d6d5a6ea9ca4a6a99791da46435b7cf@uxcn13-tdc-d.UoA.auckland.ac.nz>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/SfzROr0SqKput_PPBL_9ApjRLKw>
Subject: Re: [pkix] Why is the crlNumber an OCTET STRING?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Apr 2021 21:41:48 -0000

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 <pgut001@cs.auckland.ac.nz> 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
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix