IETF Logo Mail Archive

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

Russ Housley <housley@vigilsec.com> Wed, 21 April 2021 20:04 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 65FE43A34B3 for <pkix@ietfa.amsl.com>; Wed, 21 Apr 2021 13:04:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 HI4UthYsoq9D for <pkix@ietfa.amsl.com>; Wed, 21 Apr 2021 13:04:04 -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 D90633A34B7 for <pkix@ietf.org>; Wed, 21 Apr 2021 13:04:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 758BD300BA3 for <pkix@ietf.org>; Wed, 21 Apr 2021 16:04:02 -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 SdJdzNJ0M6eS for <pkix@ietf.org>; Wed, 21 Apr 2021 16:04:01 -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 0BD5B300AAB; Wed, 21 Apr 2021 16:04:00 -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: <f6d0bc20-2c92-3df8-a2a5-651f4e4f1dc1@aaa-sec.com>
Date: Wed, 21 Apr 2021 16:04:02 -0400
Cc: Peter Gutmann <pgut001@cs.auckland.ac.nz>, IETF PKIX <pkix@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1C41CA92-A3F7-4A99-AD7B-B4DDA710AA96@vigilsec.com>
References: <3d6d5a6ea9ca4a6a99791da46435b7cf@uxcn13-tdc-d.UoA.auckland.ac.nz> <490638C0-9D93-4998-9F5D-1C9804B8E95C@vigilsec.com> <1618955894307.55564@cs.auckland.ac.nz> <59C6BBA3-324C-4777-8A26-6E32B7D1946C@vigilsec.com> <1618957726686.74538@cs.auckland.ac.nz> <SYBPR01MB5616009D18496B7FD5CA38E1E5479@SYBPR01MB5616.ausprd01.prod.outlook.com> <1619018456026.55711@cs.auckland.ac.nz> <E16F5376-2D0F-4B04-8734-FB16892DD448@vigilsec.com> <1619020072637.77385@cs.auckland.ac.nz> <724D3978-46C6-4527-8A81-A928EEFDE217@vigilsec.com> <f6d0bc20-2c92-3df8-a2a5-651f4e4f1dc1@aaa-sec.com>
To: Stefan Santesson <stefan@aaa-sec.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/6T5kMzS2bFPoUpaHagt47JHkJxM>
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: Wed, 21 Apr 2021 20:04:06 -0000

Stefan:
> 
> 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?

If you cache CRLs to avoid fetching every time that you perform validation, then the CRL number is one way to determine whether the just fetched one is more "current" than the one in the cache.  Assuming the same scope, date works for this too as Peter pointed out.

Russ

v2.23.0 | Report a Bug | By Email