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.
- Re: [pkix] Why is the crlNumber an OCTET STRING? Russ Housley
- [pkix] Why is the crlNumber an OCTET STRING? Peter Gutmann
- Re: [pkix] Why is the crlNumber an OCTET STRING? Peter Gutmann
- Re: [pkix] Why is the crlNumber an OCTET STRING? Russ Housley
- Re: [pkix] Why is the crlNumber an OCTET STRING? Paul Hoffman
- Re: [pkix] Why is the crlNumber an OCTET STRING? Paul Hoffman
- Re: [pkix] Why is the crlNumber an OCTET STRING? Peter Gutmann
- Re: [pkix] Why is the crlNumber an OCTET STRING? Manger, James
- Re: [pkix] Why is the crlNumber an OCTET STRING? Peter Gutmann
- Re: [pkix] Why is the crlNumber an OCTET STRING? Manger, James
- Re: [pkix] Why is the crlNumber an OCTET STRING? Niklas Matthies
- Re: [pkix] Why is the crlNumber an OCTET STRING? Peter Gutmann
- Re: [pkix] Why is the crlNumber an OCTET STRING? Russ Housley
- Re: [pkix] Why is the crlNumber an OCTET STRING? Stephen Farrell
- Re: [pkix] Why is the crlNumber an OCTET STRING? Russ Housley
- Re: [pkix] Why is the crlNumber an OCTET STRING? Peter Gutmann
- Re: [pkix] Why is the crlNumber an OCTET STRING? Russ Housley
- Re: [pkix] Why is the crlNumber an OCTET STRING? Stefan Santesson
- Re: [pkix] Why is the crlNumber an OCTET STRING? Russ Housley
- Re: [pkix] Why is the crlNumber an OCTET STRING? Stefan Santesson
- Re: [pkix] Why is the crlNumber an OCTET STRING? Niklas Matthies
- Re: [pkix] Why is the crlNumber an OCTET STRING? Stefan Santesson
- Re: [pkix] Why is the crlNumber an OCTET STRING? Jeffrey Walton
- Re: [pkix] Why is the crlNumber an OCTET STRING? Peter Gutmann
- Re: [pkix] Why is the crlNumber an OCTET STRING? Ernst G Giessmann
- Re: [pkix] Why is the crlNumber an OCTET STRING? Peter Gutmann
- Re: [pkix] Why is the crlNumber an OCTET STRING? Dars, Mihran [VendorPass]