IETF Logo Mail Archive

Re: [pkix] OCSP reponses without nexUpdate

Thomas Kopp <thomas.kopp@luxtrust.lu> Mon, 24 February 2020 11:27 UTC

Return-Path: <thomas.kopp@luxtrust.lu>
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 2F6383A081B for <pkix@ietfa.amsl.com>; Mon, 24 Feb 2020 03:27:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 gyuAq1AtCH3E for <pkix@ietfa.amsl.com>; Mon, 24 Feb 2020 03:27:24 -0800 (PST)
Received: from mx1.luxtrust.lu (mx1.luxtrust.lu [185.69.225.5]) (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 B33143A081A for <pkix@ietf.org>; Mon, 24 Feb 2020 03:27:23 -0800 (PST)
Received: from SV-1447WVP05.corp.1447.local (sv-1447wvp05.corp.1447.local [10.82.96.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1.luxtrust.lu (MTA) with ESMTPS id 48R0CW2Hqkz25cw; Mon, 24 Feb 2020 12:27:19 +0100 (CET)
Received: from SV-1447WVP06.corp.1447.local (10.82.96.76) by SV-1447WVP05.corp.1447.local (10.82.96.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1847.3; Mon, 24 Feb 2020 12:27:18 +0100
Received: from SV-1447WVP06.corp.1447.local ([10.82.96.76]) by SV-1447WVP06.corp.1447.local ([10.82.96.76]) with mapi id 15.01.1847.003; Mon, 24 Feb 2020 12:27:18 +0100
From: Thomas Kopp <thomas.kopp@luxtrust.lu>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "pkix@ietf.org" <pkix@ietf.org>
Thread-Topic: OCSP reponses without nexUpdate
Thread-Index: AdXq547Yj5JHBOWqRKivA/b474BBgwACl3bgAASbi/A=
Date: Mon, 24 Feb 2020 11:27:18 +0000
Message-ID: <83b22afec0ed4ced9bdbcc90d6be6e6f@luxtrust.lu>
References: <ae45cae10fe24054b56af6af5a629f9a@luxtrust.lu> <1582535446443.55285@cs.auckland.ac.nz>
In-Reply-To: <1582535446443.55285@cs.auckland.ac.nz>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.82.96.71]
x-tm-as-product-ver: SMEX-14.0.0.3006-8.5.1024-25250.007
x-tm-as-result: No-10--18.513600-8.000000
x-tmase-matchedrid: gTucSmrmRMPuo96mfIBuopzEHTUOuMX33dCmvEa6IiGoLZarzrrPmdsb V356Z7V+rhp6tj810/e02s6J8TOQrrxKbSUBo7jQCuDAUX+yO6YpWss5kPUFdMuSXx71bvSLJ45 LyBqJh7q0mAsENODr4j3VnTxtk/KPEvPO5aZGu9urhCEFTnVAD5rMXFchDcicMv8YehqjR1UJFL hkHEcmSlcmup4sNCdTc3cn9RSV9s9Cj5bjhCk9/4SSxX6w03pu6qG5M9QNAO1O+elk6C5rQNN0i v48FC5CqxPr5qDiQQWE8dia6GlRDzTlcOjKUeYRJsXvSOBK3vrlPUem/J5c5AZdkpcZ5vP2yYfo Fmd9ELiD57Cy1hk9vgKuii9yxTyzmsV/pxO5my/M1jffIgQXhhCAX4XPOvyZtXl9IxEPXOqya7S 9hFc8qJvnD9kB0hQHhCqP3/EyOI/lbHXjaXb4vxjDRPpHuqhaU+Pb9sY4d7ObDVHFQhoExi1MHn ltY21OlQyrbycuruxT6t2V0P1GHAgi4HdkwTWaseLlFiOdASghBdUXaqx1XThdESD0qLXTFQl51 n3NhXc5jLtvL+siFmyTEFFaVEke5wuS8mCcA9/iCAiZxTARskGh+IOD+jrWuqWf6Nh7tmHfkKFD +lHaTaB2Jk8cTgr+Q7GHbf2+kKPkbDt/ykGDZqubsOtSWY2QX7bicKxRIU2No+PRbWqfRMprJP8 FBOIaDBbGvtcMofyUTGVAhB5EbQ==
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--18.513600-8.000000
x-tmase-version: SMEX-14.0.0.3006-8.5.1024-25250.007
x-tm-snts-smtp: 137A11DBD7A2DA5030E121BCFECC1764CC0AA96BBE8A58B5678BDAC113E5A4212000:8
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
x-msw-jemd-newsletter: false
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/yjiqrVY50ZrOw1Z8rhEV2bB-4_s>
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:27:25 -0000

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.

v2.23.0 | Report a Bug | By Email