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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 21 April 2021 15:21 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 C89E13A2BF3 for <pkix@ietfa.amsl.com>; Wed, 21 Apr 2021 08:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 lh0mLGv67IjO for <pkix@ietfa.amsl.com>; Wed, 21 Apr 2021 08:21:11 -0700 (PDT)
Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [103.96.23.117]) (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 C0FDB3A2BEE for <pkix@ietf.org>; Wed, 21 Apr 2021 08:21:10 -0700 (PDT)
Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2233.outbound.protection.outlook.com [104.47.71.233]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-104-u5qmfwJwPa-Lx0NZDsJnGQ-1; Thu, 22 Apr 2021 01:21:03 +1000
X-MC-Unique: u5qmfwJwPa-Lx0NZDsJnGQ-1
Received: from HK2P15301CA0003.APCP153.PROD.OUTLOOK.COM (2603:1096:202:1::13) by ME2PR01MB2225.ausprd01.prod.outlook.com (2603:10c6:201:26::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.21; Wed, 21 Apr 2021 15:21:01 +0000
Received: from HK2APC01FT059.eop-APC01.prod.protection.outlook.com (2603:1096:202:1:cafe::28) by HK2P15301CA0003.outlook.office365.com (2603:1096:202:1::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.10 via Frontend Transport; Wed, 21 Apr 2021 15:20:59 +0000
X-MS-Exchange-Authentication-Results: spf=none (sender IP is 130.216.95.224) smtp.mailfrom=cs.auckland.ac.nz; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cs.auckland.ac.nz
Received: from uxcn13-ogg-e.UoA.auckland.ac.nz (130.216.95.224) by HK2APC01FT059.mail.protection.outlook.com (10.152.249.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.4065.21 via Frontend Transport; Wed, 21 Apr 2021 15:20:58 +0000
Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.8) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 22 Apr 2021 03:20:57 +1200
Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::e4e7:eb90:ab28:1bf5]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::e4e7:eb90:ab28:1bf5%14]) with mapi id 15.00.1497.015; Thu, 22 Apr 2021 03:20:57 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "Manger, James" <James.H.Manger@team.telstra.com>, Russ Housley <housley@vigilsec.com>
CC: IETF PKIX <pkix@ietf.org>
Thread-Topic: [pkix] Why is the crlNumber an OCTET STRING?
Thread-Index: AQHXNisBKMOxCIvjxkGR+Ro1p9pc2aq9JmQAgADNMVL//zkzAIAAzrgj//9+3gCAAZbUkA==
Date: Wed, 21 Apr 2021 15:20:56 +0000
Message-ID: <1619018456026.55711@cs.auckland.ac.nz>
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>
In-Reply-To: <SYBPR01MB5616009D18496B7FD5CA38E1E5479@SYBPR01MB5616.ausprd01.prod.outlook.com>
Accept-Language: en-NZ, en-GB, en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: d58ab557-1fb1-4333-6cfb-08d904d910f4
X-MS-TrafficTypeDiagnostic: ME2PR01MB2225:
X-Microsoft-Antispam-PRVS: <ME2PR01MB222514F206E45D3813216A29EE479@ME2PR01MB2225.ausprd01.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:8273
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0
X-Microsoft-Antispam-Message-Info: M0ke3Nsw0Pu2WQ2q377mINIqm9pVL/7XOW7r6qbRWYcp4QtVeiWermb/cMuUrsTE8lSjtpZASFi7Xs0pil9Qvv25xbTr+L8yu3CsEj+C5Ep43GicPgUi10bcM8hpQAGc5JjeI4vTFAdL8+ujtsWtwJYIVWJQ2aORm/s92DjCULr0Hr9wQnxzTL1yxWsY+6lwWhf7qaXNH3nB4VN81YM7ZANSWzRjbrvH9nKbH+EgpNCfWQxqB9tNKLir1ND84dZEqNRZwTZ9gQIXZFI5UhqBRvHpXKu4IJ/2q/WbxUDfVziS4ipYtiZCa4WJeWsKMsLQDS5PSOSU+XUid/1/YR3+/SXPY4WLOt6xYFxS4cNKE/4CSkLfYFVdxfTO70axwCTQVjVIvs30tIy0YPfA3cXY1/Sw7w/G5k4mtKY8flbyib927FwYPtrA66qa2igwxvevXwNG2kQ+oVtz+mWHvDQt5DMyGbrR2R+QD+oGb4nBVWXUUCdlJdVbXz9jCiypjGChoANAstK32PWPKGEry+od6T92SqLzR/Icq/F9MF58J0BX2+HEp146SEKv7iJOuxbZmjen/3Ewuwr2hEmUi9Qb9p5rDD8zMDJeR6puxQpzY5pOhm9DFFrewe5wjJUPsB7ud2Tcq6G8YLvY6AguXWCgqQ==
X-Forefront-Antispam-Report: CIP:130.216.95.224; CTRY:NZ; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:uxcn13-ogg-e.UoA.auckland.ac.nz; PTR:natgate2-1.auckland.ac.nz; CAT:NONE; SFS:(4636009)(346002)(39850400004)(376002)(396003)(136003)(36840700001)(46966006)(36906005)(2906002)(7636003)(186003)(2616005)(82310400003)(83380400001)(786003)(478600001)(316002)(70206006)(110136005)(82740400003)(5660300002)(86362001)(336012)(26005)(356005)(8936002)(70586007)(8676002)(4326008)(47076005)(36860700001); DIR:OUT; SFP:1101
X-OriginatorOrg: cs.auckland.ac.nz
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Apr 2021 15:20:58.5055 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d58ab557-1fb1-4333-6cfb-08d904d910f4
X-MS-Exchange-CrossTenant-Id: d1b36e95-0d50-42e9-958f-b63fa906beaa
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d1b36e95-0d50-42e9-958f-b63fa906beaa; Ip=[130.216.95.224]; Helo=[uxcn13-ogg-e.UoA.auckland.ac.nz]
X-MS-Exchange-CrossTenant-AuthSource: HK2APC01FT059.eop-APC01.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME2PR01MB2225
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: cs.auckland.ac.nz
Content-Language: en-NZ
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/ChKQ9c3BeTMap9lPbwyIWkmc1CA>
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 15:21:16 -0000

Manger, James <James.H.Manger@team.telstra.com> writes:

>Presumably CRLNumber has the “20 octet” language merely for consistency with
>CertificateSerialNumber. They sound so similar: numbering CRLs vs numbering
>certs.

Just noticed that the RFC text kinda confirms this:

   As noted in Section 4.1.2.2, serial numbers can be expected to
   contain long integers.  Certificate users MUST be able to handle
   serialNumber values up to 20 octets in length.  Conforming CAs MUST
   NOT use serialNumber values longer than 20 octets.

   As noted in Section 5.2.3, CRL numbers can be expected to contain
   long integers.  CRL validators MUST be able to handle cRLNumber
   values up to 20 octets in length.  Conforming CRL issuers MUST NOT
   use cRLNumber values longer than 20 octets.

So it's a cut&paste of the text for certificate serial numbers, for which
there's a legitimate reason, the German tank problem, to not use actual serial
numbers.

>It is almost conceivable that a CA could hash the details of a CRL’s scope,
>then replace the least-significant, say, 64 bits with nano-seconds-since-1970

Or ISO 8601 dates stuffed into the "serial number" for the CRL.

That does actually point out another issue though:

   The CRL number is a non-critical CRL extension that conveys a
   monotonically increasing sequence number for a given CRL scope and
   CRL issuer.  This extension allows users to easily determine when a
   particular CRL supersedes another CRL.

Isn't that what the dates in the CRL are for?  The only argument I can see for
using crlNumber is if you're brave enough to risk using delta CRLs.

Peter.