Re: [pkix] Optimizing OCSP - Time for some spec work ?

Peter Gutmann <pgut001@cs.auckland.ac.nz> Fri, 25 October 2019 02:04 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 7A3BA120236 for <pkix@ietfa.amsl.com>; Thu, 24 Oct 2019 19:04:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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=auckland.ac.nz
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 TFfPU9hKCPtn for <pkix@ietfa.amsl.com>; Thu, 24 Oct 2019 19:04:14 -0700 (PDT)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 0419212084D for <pkix@ietf.org>; Thu, 24 Oct 2019 19:04:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1571969055; x=1603505055; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sintOilD5clFJtJdZJQZe5a6BdnK4YY86kDtUykbj70=; b=vNM5xfyhO6axwj6ABclveTIIHTCcfCX/X58WdhburGnLtxY61i3W8qdk lyYjjTl+Rra1dx2OZiRFpnOsYC6asUj/UBdtQaY+wmJJfpVWcsfvrcgHd mPeoD0r9a45QAxZxPFgu9wiLUjfvDMItgxFtEWkn5+M4ONyPPA7o/uFDU pr6q/BxpvI/OpMHq18EEZ/SgViqMMqE+wdG0Qd7DdFplGh3dHBT9zWSpB DGW5PFgw1It0mRJzm2eD93F40NiZcj7k17hoWIHtZrJSVMJuTY29xa655 2lIxZItnW+ukR3xcG6xBsf1MdN9G/NAh6lpEUbFk9oGiobWfiHLqBDykn g==;
X-IronPort-AV: E=Sophos;i="5.68,226,1569240000"; d="scan'208";a="95975620"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Oct 2019 15:04:13 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 25 Oct 2019 15:04:11 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Fri, 25 Oct 2019 15:04:11 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Kurt Roeckx <kurt@roeckx.be>, "Dr. Pala" <madwolf@openca.org>
CC: PKIX <pkix@ietf.org>
Thread-Topic: [pkix] Optimizing OCSP - Time for some spec work ?
Thread-Index: AQHVinrq4I5nEcgfh0O9xU1lviUJBKdpDG6AgAGO0P8=
Date: Fri, 25 Oct 2019 02:04:11 +0000
Message-ID: <1571969051579.18927@cs.auckland.ac.nz>
References: <31256d2d-dcfb-85f7-3850-accb2b2d6b89@openca.org>, <20191024151359.GE6530@roeckx.be>
In-Reply-To: <20191024151359.GE6530@roeckx.be>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/yEJJqvOzCAr0wTauJOMDE4CQhzg>
Subject: Re: [pkix] Optimizing OCSP - Time for some spec work ?
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: Fri, 25 Oct 2019 02:04:16 -0000

Kurt Roeckx <kurt@roeckx.be> writes:

>I don't see how that can work if you're not allowed to return good for a 
>non-issued certificate 

RFC 6960 says:

   The "good" state indicates a positive response to the status inquiry.  
   At a minimum, this positive response indicates that no certificate
   with the requested certificate serial number currently within its
   validity interval is revoked.  This state does not necessarily mean
   that the certificate was ever issued or that the time at which the
   response was produced is within the certificate's validity interval.

So you're explicitly permitted to return "good" for a non-issued certificate.
   
>and that the serial numbers should be random.

How would the way serial numbers are generated affect things?  In other
words, to reverse your comment, how would it *not* work with random serial
numbers?

Peter.