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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 21 April 2021 02:50 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 219263A0FDF for <pkix@ietfa.amsl.com>; Tue, 20 Apr 2021 19:50:48 -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 kHndvc_1S5sr for <pkix@ietfa.amsl.com>; Tue, 20 Apr 2021 19:50:44 -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 7D8D33A0FDE for <pkix@ietf.org>; Tue, 20 Apr 2021 19:50:42 -0700 (PDT)
Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2240.outbound.protection.outlook.com [104.47.71.240]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-70-ZnF7PL9fOcKFOThlfvZa4w-1; Wed, 21 Apr 2021 12:50:37 +1000
X-MC-Unique: ZnF7PL9fOcKFOThlfvZa4w-1
Received: from PS2PR03CA0021.apcprd03.prod.outlook.com (2603:1096:300:5b::33) by MEYPR01MB7213.ausprd01.prod.outlook.com (2603:10c6:220:144::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.19; Wed, 21 Apr 2021 02:50:30 +0000
Received: from HK2APC01FT037.eop-APC01.prod.protection.outlook.com (2603:1096:300:5b::4) by PS2PR03CA0021.outlook.office365.com (2603:1096:300:5b::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.6 via Frontend Transport; Wed, 21 Apr 2021 02:50:30 +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-tdc-c.UoA.auckland.ac.nz (130.216.95.224) by HK2APC01FT037.mail.protection.outlook.com (10.152.248.223) 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 02:50:29 +0000
Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.4) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 21 Apr 2021 14:50:28 +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; Wed, 21 Apr 2021 14:50:28 +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+3gCAAMpoTg==
Date: Wed, 21 Apr 2021 02:50:27 +0000
Message-ID: <1618973426649.81377@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: 3038a9b8-37b3-46c1-725a-08d90470398d
X-MS-TrafficTypeDiagnostic: MEYPR01MB7213:
X-Microsoft-Antispam-PRVS: <MEYPR01MB72139678D399A06ADCA4EE67EE479@MEYPR01MB7213.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: SIb0yjqztrPvPOTjB2J4dRezZtx/ryv70ZBXLUQUUZ3c82ZMdCmZQKT0sRQmw/biEmNb40IptChupm44qhyzSG4epGFgsYkqX/krSpPv8DnTzpIK4wNWwBGkw21t9Kw5n4sZU3sZB/voex++CtHSr2rCXBxq8pDZjMTDH8BuBTdzTkjD7CvB/1Ub281MDoJrnHkE3siVe9bKlskW0mMXMxn+r23mw2Pz9hE1FFufRo1Buc+rZhDNkpNQyjHSUUbvX/akDjdmQ56Io5gFb409MG8u4z/Iz4PXMZLm1oIy+USrqkXvsCo6YU6RLTKZ6ZpruyYoePJ107RbqXuRVA1sRnPn7Po2v37ox0OOYRjB1EAsCAS9+vggsI5Fkrs0WIJxvCB2Wh20jdEj+9O874BEXagg8r8z4SGNQys7E3JEw/AbGX52CllB2vFi2tyZYdUpbZT74y3cNq1iXAzzkwgRdIK+eNDTSlGJ0Pt7aNC/K9JmCGijTJNfoo4hrszMhO4supNvNN0yyK8uWVbrEMVCdP9JrayQ0G5HaBGDZoHrLaL7zdHAok2wnBh7sQ0/Kb36NhWp2bMPONO16rBkCJz8MMDEckFoKdVLO0xkTfsnKSXegPM9Rr7MDqrcam2Y/hLQ+pnVJCIZdMXP8AwPKih1gw==
X-Forefront-Antispam-Report: CIP:130.216.95.224; CTRY:NZ; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:uxcn13-tdc-c.UoA.auckland.ac.nz; PTR:natgate2-1.auckland.ac.nz; CAT:NONE; SFS:(4636009)(39860400002)(136003)(396003)(376002)(346002)(46966006)(36840700001)(5660300002)(8676002)(478600001)(356005)(4326008)(316002)(786003)(70586007)(36906005)(110136005)(82740400003)(66574015)(36860700001)(82310400003)(2906002)(47076005)(83380400001)(4744005)(8936002)(86362001)(336012)(7636003)(70206006)(26005)(186003)(2616005); DIR:OUT; SFP:1101
X-OriginatorOrg: cs.auckland.ac.nz
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Apr 2021 02:50:29.4706 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3038a9b8-37b3-46c1-725a-08d90470398d
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-tdc-c.UoA.auckland.ac.nz]
X-MS-Exchange-CrossTenant-AuthSource: HK2APC01FT037.eop-APC01.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEYPR01MB7213
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/YtwW0J0Xie_Xqe6ldS3LG9xhWEE>
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 02:50:48 -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.

Ah, that would make sense.

Just for fun, I thought about what it would take to blow past the limits of a
generic integer value, say 64 bits.  It's not just a case of running a counter
up to whatever number it is that a twenty-byte value is called, you need to
sign and publish a CRL for each one.  Let's say, rather optimistically, that
you can do a hundred a second (since it's not just raw sigs but actually
assembling and publishing a CRL), so you're doing ~10M a day.  That's about 5
billion years of issuing CRLs as fast as you can to exceed what an integer
value can hold.

Looked at another way, if you've got some way you can run something that
requires 2^160 operations you'll be doing other things, probably related to
BTC, with it instead of mucking around with PKI.

Peter.