Re: [pkix] OCSP reponses without nexUpdate

Peter Gutmann <pgut001@cs.auckland.ac.nz> Mon, 24 February 2020 09:10 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 367963A0969 for <pkix@ietfa.amsl.com>; Mon, 24 Feb 2020 01:10:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, 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 JuHhrtNBhr7e for <pkix@ietfa.amsl.com>; Mon, 24 Feb 2020 01:10:51 -0800 (PST)
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 E8B133A0968 for <pkix@ietf.org>; Mon, 24 Feb 2020 01:10:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1582535451; x=1614071451; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jrojnSXO+HF7OPwwd3FzEYFvwIg0EV/KPzgPr9GRUbE=; b=UXI+mrzI4Wx3atZHLrueqWo3NaJ6lfEOjweYHUVznwMxO+9CtFA/hfp4 1Ut/ij9ZNMTIFU+2OcrCpnzWfV1AhWofvpEq2lqUYdSAVrrjT53MC3X3v jskkZhnvxOU0wXCQAC4U3R71nV+lSjDB0vQ9r0KX94PNddDvq71SoOnQ2 dym150kT4zWHXbftkOVTe0jll+SIcb4ZHC7c6Bh5l8LofO3Qh7YNirL5u r3TxUFqoKRHhwq1wuziAw2/4xa1Ms+RBrZiGc7Ytr7ASmyBJT2Yz3ZoGl fdrf5br+dkn3em+229hlEdIJzE5HeUc0r4Hc+GQcFieJM1TPxtYhp9HCX w==;
X-IronPort-AV: E=Sophos;i="5.70,479,1574074800"; d="scan'208";a="116982224"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing
Received: from uxcn13-ogg-e.uoa.auckland.ac.nz ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 24 Feb 2020 22:10:48 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.8) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 24 Feb 2020 22:10:47 +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; Mon, 24 Feb 2020 22:10:47 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Thomas Kopp <thomas.kopp@luxtrust.lu>, "pkix@ietf.org" <pkix@ietf.org>
Thread-Topic: OCSP reponses without nexUpdate
Thread-Index: AdXq547Yj5JHBOWqRKivA/b474BBgwACl3bg
Date: Mon, 24 Feb 2020 09:10:47 +0000
Message-ID: <1582535446443.55285@cs.auckland.ac.nz>
References: <ae45cae10fe24054b56af6af5a629f9a@luxtrust.lu>
In-Reply-To: <ae45cae10fe24054b56af6af5a629f9a@luxtrust.lu>
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/jmq0bEiWy94E0seHETNJkBNFaaA>
Subject: Re: [pkix] OCSP reponses without nexUpdate
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: Mon, 24 Feb 2020 09:10:53 -0000

Thomas Kopp <thomas.kopp@luxtrust.lu> writes:

>Does it mean for subsequent requests that one of the fields  thisUpdate or
>producedAt must change even if certificate status has not changed?

Yes, no, and maybe.  If you're applying strict CRL compatibility, you set it
to the CRL nextUpdate time.  If you decide that since it's an online service
another update can become available at any time, you set it the current time.
If you're running CRLs at the same time, you set it to the next CRL production
time.  If you're doing batch signing to deal with OCSP's non-scalability, in
other words pre-producing responses, you set it to when the next batch of
responses get signed.  If you believe the Martians are coming, you set it to
just before they land so there's no expectations of OCSP responses after
they've killed us all.

If you don't believe any of the above then feel free to come up with another
interpretation and use that.  See long-ago threads on this list for more
suggestions on how this field can be interpreted (I can't remember all of the
variants).

Another interpretation is to do whatever makes sense to you and put it in your
CPS.

Peter.