Re: [pkix] OCSP reponses without nexUpdate

Peter Gutmann <pgut001@cs.auckland.ac.nz> Mon, 24 February 2020 11:29 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 0D12F3A0829 for <pkix@ietfa.amsl.com>; Mon, 24 Feb 2020 03:29:47 -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 8R4LZE0Xo5Eg for <pkix@ietfa.amsl.com>; Mon, 24 Feb 2020 03:29:45 -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 0781A3A0821 for <pkix@ietf.org>; Mon, 24 Feb 2020 03:29:44 -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=1582543785; x=1614079785; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=oycfIB4VEc2a7Q5cJZZhwFki4V3NwcwypEQRhUFOhdc=; b=0iGbcWJAHKfiWErZAtkVeZNgOyAlZXayiAezZ3iCaobuYIMcQggVMzhI Ok5jzt/u0Gh+J3YBL9+udacuKMepn5Oqizd11kOdFK86gkWQudbWFLzQb rlVxPm9LjRTkBad4x+pkM8iLq49oVD/7PMR/qXyUa0w2fzLb8mJnmXbA4 jXvDCGwsJKUK4rc0Jm8kQGmLwjKSHoqUg3hgB7kv3dWWPdsmuT+WJY+D+ 3sVzZk6LLVViT/cJJ87AMwn+NJWAR8fyVoqpsa8eMr/zuL9FGvRTDt6Aw 0/rBlIAMF0Wlb52xQNWW4Ew3P1YqRJX/4+wyJsqSYSFNcGa3oRQaIZ0ZS A==;
X-IronPort-AV: E=Sophos;i="5.70,480,1574074800"; d="scan'208";a="116996937"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing
Received: from uxcn13-ogg-c.uoa.auckland.ac.nz ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Feb 2020 00:29:43 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 25 Feb 2020 00:29:42 +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; Tue, 25 Feb 2020 00:29:42 +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/b474BBgwACl3bgAASbi/AAAEgzLw==
Date: Mon, 24 Feb 2020 11:29:42 +0000
Message-ID: <1582543781851.26991@cs.auckland.ac.nz>
References: <ae45cae10fe24054b56af6af5a629f9a@luxtrust.lu> <1582535446443.55285@cs.auckland.ac.nz>, <83b22afec0ed4ced9bdbcc90d6be6e6f@luxtrust.lu>
In-Reply-To: <83b22afec0ed4ced9bdbcc90d6be6e6f@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/ICZf1r1EA6XqfXusZnheZib4yao>
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 11:29:47 -0000

The point is that no-one can agree on an interpretation, so if one person says
X then the next person you ask might say ~X.  That's why I suggested putting
it in your CPS, at least then it's documented for anyone who wants to see it.

Peter.

________________________________________
From: Thomas Kopp <thomas.kopp@luxtrust.lu>
Sent: Tuesday, 25 February 2020 00:27
To: Peter Gutmann; pkix@ietf.org
Subject: RE: OCSP reponses without nexUpdate

Thanks a lot Peter for this obviously very flexible interpretation of the RFC's "newer" semantics.
Hopefully also others, in particular authors of RFC 6960, might provide some complementary advice.

Thomas KOPP
Chief Scientist

Email: thomas.kopp@luxtrust.lu
Mobile:+352 621 229 316
Office: +352 26 68 15 - 574
LuxTrust S.A. |  IVY Building | 13-15, Parc d'activit├ęs | L-8308 Capellen | Luxembourg | www.luxtrust.lu




The information in this e-mail and any attachment is confidential and for use by the addressee only. Access to this e-mail by anyone else is not authorized. If you are not the intended recipient, please inform the sender and erase all copies of it from your system. Internet communications are by default not secure. LuxTrust S.A. cannot guarantee the integrity and origin of e-mails unless they have been properly digitally signed. Confidentiality of e-mails can only be guaranteed if they are encrypted properly using a secure digital certificate.LuxTrust S.A. takes precautions to ensure that e-mails are scanned for viruses but cannot accept liability for any damage sustained as a result of software viruses.


-----Original Message-----
From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]
Sent: Monday, February 24, 2020 10:11 AM
To: Thomas Kopp; pkix@ietf.org
Subject: Re: OCSP reponses without nexUpdate

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.