IETF Logo Mail Archive

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

Jeffrey Walton <noloader@gmail.com> Thu, 22 April 2021 03:29 UTC

Return-Path: <noloader@gmail.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 271A83A1311 for <pkix@ietfa.amsl.com>; Wed, 21 Apr 2021 20:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.com
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 2gpYTVkxhP9z for <pkix@ietfa.amsl.com>; Wed, 21 Apr 2021 20:28:58 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1863A130F for <pkix@ietf.org>; Wed, 21 Apr 2021 20:28:58 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id k25so1130041iob.6 for <pkix@ietf.org>; Wed, 21 Apr 2021 20:28:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=9sYVcfmwjs5tr0U+9mnvzfMSY3A3tardkAlLMvojJPY=; b=mTHXYdU0iGly8qMT/26MUaaUjFYDVksCSWwEcwUU/Wh9XPITIUmA+5B5kkOBpIM5e5 xmMOuoHOxSSrFBVQasi7+zNC6wyj4uw9iBnIMex0EOu+BkMdWp2jLiq+v/D2yLfvglfI 3h28v8dDolV0u4TCg/G4emdydHgfW7ck1kVT++RtAVTBVfADiqpt9V0JUUpMo3KPehQ8 V9Na38PYCNJ5ixPRbDr/6zC1U7fyBB/SquPmJ99FgZJ4x9BPBTgC465200a82O0X36Ya dkwl+Yy+/KvbzxyS58o+f48dXI4hjE3E1LOepQ9KppuZL56GD4Yc7DJ3AXy7ew6V95SP ZgWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=9sYVcfmwjs5tr0U+9mnvzfMSY3A3tardkAlLMvojJPY=; b=qQXbGVEKOmAnZI5qT+zNULM5/bKmwZcnOlWNeiw5WVBNI0WpQu/QPoftwzTjxWQIE8 lRMKXxQrfiljUwkZTYKDrU4QNgyYmuN/ionjHS2Iv9CwWgQ0UzXDmgnDlSUIJD2qvczH XLat4Jh7wgMQd4wly2x76AoUA4l6B0/+WsR/cV2sqMXjLAG1gtGg9bwI7ULF/DVR9szB pWzNUpmQ2JtrC19vi7DPTWOu+wEvpvd8mmcTT4Tf+qGgfjPVJfOK8MlvwK6q4fmkCpmB IzNw/cAANi83lczAcJ0peh9SzaGhm81WK6h7HktRYlPTRS9LaXsT4BHgXOcrz6FUFC8j McsQ==
X-Gm-Message-State: AOAM531yJOv9qL6VFblm0HPS4/xaG+ppKvydwtwx6Qkhl423EMt0eJPz ZZGbcY4aDsIAUycV7gw7dax856NrDrYEuhIZczQnfpkFRoI=
X-Google-Smtp-Source: ABdhPJwiRnmuRgUs5rKVnA3Xdu7Flhy+dZisrRK+1itD4v+0NzRmC0QtAxOy6M3rIRjd34W9kUmV/9B0sgoxqGQBzO0=
X-Received: by 2002:a02:1989:: with SMTP id b131mr1384905jab.54.1619062136965; Wed, 21 Apr 2021 20:28:56 -0700 (PDT)
MIME-Version: 1.0
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> <5e307e5e-1509-f588-a27e-79dd6af910a4@aaa-sec.com>
In-Reply-To: <5e307e5e-1509-f588-a27e-79dd6af910a4@aaa-sec.com>
Reply-To: noloader@gmail.com
From: Jeffrey Walton <noloader@gmail.com>
Date: Wed, 21 Apr 2021 23:28:43 -0400
Message-ID: <CAH8yC8nbBKd3_gSYqOUMkAsE4yZhcW7m-fvqt+4+PG5A8Qg-eQ@mail.gmail.com>
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: IETF PKIX <pkix@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/qCwoKDOQ5MNDfg4oH4Mk24l8vpE>
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 03:29:03 -0000

On Wed, Apr 21, 2021 at 4:19 PM Stefan Santesson <stefan@aaa-sec.com> wrote:
>
> 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.

It would make sense to use the existing CRL if the CRL has not changed
if it is expensive to download a CRL. The use case would include a
large PKI, like a federal PKI with a CRL that is hundreds of MB, and a
mobile client over 3G on a restrictive data plan.

Jeff

v2.23.0 | Report a Bug | By Email