Re: [pkix] OCSP reponses without nexUpdate

[Thomas Kopp <[e-mail]>]

Indeed, this makes sense. Thanks, again!

Thomas KOPP
Chief Scientist

Email: [e-mail]
Mobile:[phone]
Office: [phone] - 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:[e-mail]] 
Sent: Monday, February 24, 2020 12:30 PM
To: Thomas Kopp; [e-mail]
Subject: Re: OCSP reponses without nexUpdate

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 <[e-mail]>
Sent: Tuesday, 25 February 2020 00:27
To: Peter Gutmann; [e-mail]
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: [e-mail]
Mobile:[phone]
Office: [phone] - 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:[e-mail]]
Sent: Monday, February 24, 2020 10:11 AM
To: Thomas Kopp; [e-mail]
Subject: Re: OCSP reponses without nexUpdate

Thomas Kopp <[e-mail]> 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.