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

Niklas Matthies <pkix@nmhq.net> Wed, 21 April 2021 20:52 UTC

Return-Path: <pkix@nmhq.net>
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 013B53A342B for <pkix@ietfa.amsl.com>; Wed, 21 Apr 2021 13:52:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 xPacloG69yx3 for <pkix@ietfa.amsl.com>; Wed, 21 Apr 2021 13:51:59 -0700 (PDT)
Received: from mail.nmhq.net (mail.nmhq.net [95.129.49.110]) (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 B306D3A3648 for <pkix@ietf.org>; Wed, 21 Apr 2021 13:51:34 -0700 (PDT)
Received: from matthies by mail.nmhq.net with local (Exim 4.89) (envelope-from <pkix@nmhq.net>) id 1lZJop-000605-Nv for pkix@ietf.org; Wed, 21 Apr 2021 22:51:31 +0200
Date: Wed, 21 Apr 2021 22:51:31 +0200
From: Niklas Matthies <pkix@nmhq.net>
To: pkix@ietf.org
Message-ID: <20210421205131.gd6quhamcgkgc2lt@nmhq.net>
Mail-Followup-To: pkix@ietf.org
References: <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> <5e307e5e-1509-f588-a27e-79dd6af910a4@aaa-sec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <5e307e5e-1509-f588-a27e-79dd6af910a4@aaa-sec.com>
X-Clacks-Overhead: GNU Terry Pratchett
X-Editor: VIM - Vi IMproved 8.0
X-Operating-System: Linux 4.4.112 x86_64
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/Mq7db3EIJkycCbp9z1-nyCwv1aY>
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:52:04 -0000

In case of revocations, a new CRL is generally issued before
NextUpdate. Therefore it makes sense to regularly refresh the cache
entry regardless of the NextUpdate value, in order to limit (based on
local policy) the delay of noticing a new revocation. And then you
could conceivably compare the CRL number and abort the refresh if it's
still the same, as a performance optimization.

However, I would agree that comparing ThisUpdate makes more sense,
also because it's one of the first fields of a CRL and thus more
quickly accessible.

Niklas


On Wed 2021-04-21 at 22:18h, Stefan Santesson wrote on pkix:
>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
>
>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix