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

Stefan Santesson <stefan@aaa-sec.com> Wed, 21 April 2021 21:08 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 2E7EB3A36ED for <pkix@ietfa.amsl.com>; Wed, 21 Apr 2021 14:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, 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, 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 UZ-vZzwv5Q1J for <pkix@ietfa.amsl.com>; Wed, 21 Apr 2021 14:08: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 B10CA3A36EC for <pkix@ietf.org>; Wed, 21 Apr 2021 14:08:03 -0700 (PDT)
Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with UTF8SMTP id 453B12E686A3 for <pkix@ietf.org>; Wed, 21 Apr 2021 23:07:59 +0200 (CEST)
Received: from s934.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with UTF8SMTP id 36B522E686AF for <pkix@ietf.org>; Wed, 21 Apr 2021 23:07:59 +0200 (CEST)
Received: from s898.loopia.se (unknown [172.22.191.5]) by s934.loopia.se (Postfix) with UTF8SMTP id 355CB7CE9BA for <pkix@ietf.org>; Wed, 21 Apr 2021 23:07:59 +0200 (CEST)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s630.loopia.se ([172.22.191.5]) by s898.loopia.se (s898.loopia.se [172.22.190.17]) (amavisd-new, port 10024) with UTF8LMTP id 888n8PRO1R5P for <pkix@ietf.org>; Wed, 21 Apr 2021 23:07: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 9C2FC13B9442 for <pkix@ietf.org>; Wed, 21 Apr 2021 23:07:58 +0200 (CEST)
Message-ID: <9340b576-ec59-f88e-bf74-cfe70f8e07d8@aaa-sec.com>
Date: Wed, 21 Apr 2021 23:07: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: sv-SE
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> <20210421205131.gd6quhamcgkgc2lt@nmhq.net>
From: Stefan Santesson <stefan@aaa-sec.com>
Organization: 3xA Security AB
In-Reply-To: <20210421205131.gd6quhamcgkgc2lt@nmhq.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/IZ2IGA-f0SCDFbnOFwY4V4Fee0Q>
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 21:08:08 -0000

Niklas,

Thanks for refreshing my memory. Yes, that is actually the process I
follow. Including comparison of ThisUpdate.

I just clearly recalled that I never saw the need to compare CRLNumber.

But I guess that is not what this thread attempted to solve. Sorry for
the side-tracking.

/Stefan


On 2021-04-21 22:51, Niklas Matthies wrote:
> 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
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix