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

Ernst G Giessmann <giessman@informatik.hu-berlin.de> Thu, 22 April 2021 16:58 UTC

Return-Path: <giessman@informatik.hu-berlin.de>
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 B12583A0A2E for <pkix@ietfa.amsl.com>; Thu, 22 Apr 2021 09:58:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=informatik.hu-berlin.de
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 npxq8IgWtUXh for <pkix@ietfa.amsl.com>; Thu, 22 Apr 2021 09:58:15 -0700 (PDT)
Received: from mailout1.informatik.hu-berlin.de (mailout1.informatik.hu-berlin.de [141.20.20.101]) (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 928EC3A0A29 for <pkix@ietf.org>; Thu, 22 Apr 2021 09:58:14 -0700 (PDT)
Received: from mailbox.informatik.hu-berlin.de (mailbox [141.20.20.63]) by mail.informatik.hu-berlin.de (8.15.1/8.15.1/INF-2.0-MA-SOLARIS-2.10-25) with ESMTPS id 13MGw6VA017660 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <pkix@ietf.org>; Thu, 22 Apr 2021 18:58:06 +0200 (MEST)
Received: from [192.168.2.102] (p2e57c329.dip0.t-ipconnect.de [46.87.195.41]) (authenticated bits=0) by mailbox.informatik.hu-berlin.de (8.15.1/8.15.1/INF-2.0-MA-SOLARIS-2.10-AUTH-26-465-587) with ESMTPSA id 13MGw3u0017581 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=OK) for <pkix@ietf.org>; Thu, 22 Apr 2021 18:58:06 +0200 (MEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=informatik.hu-berlin.de; s=mailbox; t=1619110686; bh=XE7MM4yZ0wez4IvHNNEduUVPRtdCik5VMABeEPSr+2M=; h=To:References:From:Subject:Date:In-Reply-To; b=jKufP24SgZczoDvumpG7hoVtYiyoUVV62nJGGcTEwqh5raC61Jxu3LVex1pkmrmVH CsiXGpl9KtZJkr5sfbsCzMRXs4yaJgFUYtW+x+P2Bn3bEddmNN+iTAnVj3UJyA+X1Y A1BkpK5NiwZujFOTWXqWlU3f1YEJx4Tga16dtoPw=
To: 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> <1619090483847.17566@cs.auckland.ac.nz>
From: Ernst G Giessmann <giessman@informatik.hu-berlin.de>
Message-ID: <a9032193-801e-a65b-cc3b-a0dc6e366aa0@informatik.hu-berlin.de>
Date: Thu, 22 Apr 2021 18:58:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <1619090483847.17566@cs.auckland.ac.nz>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.102.3 at mailbox
X-Virus-Status: Clean
X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.6.1 (mail.informatik.hu-berlin.de [141.20.20.50]); Thu, 22 Apr 2021 18:58:06 +0200 (MEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/VCVcG5d88rnYzFmcRaMwXfT2FV0>
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: Thu, 22 Apr 2021 16:58:21 -0000

Stefan,
nevertheless it could happen, that you got two different CRLs, e.g. from
two different CRL distribution points, both valid (current time inside
thisUpdate and NextUpdate). How you decide which is the "current"?
Comparing the corresponding thisUpdate information? And if they are the
same due to lousy accuracy?
If you always implemented it this way, then your implementations are
wrong. The correct check is comparing the CRL numbers.
Sorry.
/Ernst.

Am 2021-04-22 um 13:21 schrieb Peter Gutmann:
> Stefan Santesson <stefan@aaa-sec.com> writes:
> 
>> 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.
> 
> Same here, could never figure out what the purpose of it was.  Russ' answer
> about partitioned CRLs makes sense, but I'd never even considered that
> because, like delta CRLs, I've never encountered anyone brave enough to want
> to see what clients do in response to seeing one.
> 
>> 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.
> 
> Yup.
> 
>> So basically, I find this interesting intellectually, but in what practical
>> context does this matter?
> 
> I've got a client who asked about it, and my response of "I have no idea what
> purpose these things serve" was possibly a bit underwhelming :-).
> 
> Peter.
> 
> 
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>