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

Stefan Santesson <stefan@aaa-sec.com> Wed, 21 April 2021 20:19 UTC

Return-Path: <stefan@aaa-sec.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 D1AE23A352D for <pkix@ietfa.amsl.com>; Wed, 21 Apr 2021 13:19:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 eh0NSycV-EgJ for <pkix@ietfa.amsl.com>; Wed, 21 Apr 2021 13:19:04 -0700 (PDT)
Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [93.188.3.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE2A3A352C for <pkix@ietf.org>; Wed, 21 Apr 2021 13:19:03 -0700 (PDT)
Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with UTF8SMTP id E5CB21AA20A7 for <pkix@ietf.org>; Wed, 21 Apr 2021 22:18:59 +0200 (CEST)
Received: from s645.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with UTF8SMTP id D63122E3A0C9; Wed, 21 Apr 2021 22:18:59 +0200 (CEST)
Received: from s470.loopia.se (unknown [172.22.191.6]) by s645.loopia.se (Postfix) with UTF8SMTP id C44E2157A03A; Wed, 21 Apr 2021 22:18:59 +0200 (CEST)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s630.loopia.se ([172.22.191.5]) by s470.loopia.se (s470.loopia.se [172.22.190.10]) (amavisd-new, port 10024) with UTF8LMTP id wvSG85SitViO; Wed, 21 Apr 2021 22:18:58 +0200 (CEST)
X-Loopia-Auth: user
X-Loopia-User: mailstore2@aaa-sec.com
X-Loopia-Originating-IP: 90.229.17.25
Received: from [10.0.1.104] (unknown [90.229.17.25]) (Authenticated sender: mailstore2@aaa-sec.com) by s630.loopia.se (Postfix) with UTF8SMTPSA id B92FD13B9442; Wed, 21 Apr 2021 22:18:58 +0200 (CEST)
Message-ID: <5e307e5e-1509-f588-a27e-79dd6af910a4@aaa-sec.com>
Date: Wed, 21 Apr 2021 22:18:58 +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 <housley@vigilsec.com>
Cc: Peter Gutmann <pgut001@cs.auckland.ac.nz>, IETF PKIX <pkix@ietf.org>
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> <1C41CA92-A3F7-4A99-AD7B-B4DDA710AA96@vigilsec.com>
From: Stefan Santesson <stefan@aaa-sec.com>
Organization: 3xA Security AB
In-Reply-To: <1C41CA92-A3F7-4A99-AD7B-B4DDA710AA96@vigilsec.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/ciFaioYg2_p8r8oHlZdzL3RUVKg>
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:19:07 -0000

Yes, I understand the logic. I just say that as implementer I never
found the reason to use this in practice.

In practice I have a policy that test if my current cached CRL is valid
to use. If yes, then I use it. if no, then I discard it and attempts to
get a new CRL.

The new CRL is treated the same way before being used.

Perhaps my implementations are to simplistic, but I never found a
compelling reason to check and compare CRL number.

/Stefan

On 2021-04-21 22:04, Russ Housley wrote:
> 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