Re: Optimizing OCSP - Time for some spec work ?

Actually, this the is widely used, but
not in the way you are suggesting. The use case for the text below
is included in the quoted text: "to improve response
pre-generation performance or cache efficiency."

Take as an example the CA that issued
my PIV Authentication certificate. If I query the CA's OCSP
responder about the status of my certificate I get back an OCSP
response that includes status information for 20 certificates
issued by that CA: my certificate and 19 others. According to the
"Produced At" time in the response, the response was generated
about 45 minutes before I sent my request.

This suggests that the OCSP responder
is serving pre-generated responses, and in order to speed up the
pre-generation of responses, it is generating one response for
every 20 certificates rather than one for every certificate.

The extra OCSP responses are not
providing information about other certificates that I want to know
the status of, they are providing information about other
certificates that I most likely don't care about. My client just
needs to know that the OCSP response may contain additional
SingleResponse elements so that it knows to ignore them and to
check every SingleResponse element to see if any of them covers
the certificate that was asked about.

On 10/25/19 2:51 PM, Dr. Pala wrote:

Hi Niklas,

thanks for pointing that out - that paragraph is quite
difficult to interpret correctly (I guess that is why nobody is
attaching extra OCSP responses). In fact the text reads:

The response SHOULD NOT include any additional
SingleResponse elements, but, for example, OCSP responders that
pre-generate status responses might include additional SingleResponse
elements if necessary to improve response pre-generation performance
or cache efficiency (according to [RFC5019], Section 2.2.1).

and it starts with a SHOULD NOT :D I guess this was an attempt
to provide some capability here, but did not provide the
use-case for it. - therefore support for "extra" responses is
quite interesting. When reading this paragraph, my first
reaction as a developer is NOT to implement that feature.

Also, if you think about it, there is a Trust problem - why
shall I trust this CA's responder to provide responses up in the
chain ?

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix