Re: Optimizing OCSP - Time for some spec work ?

Hi Max,

Just to chime in regarding the first reason: OCSP responses are 
allowed to include additional single responses that weren't explicitly 
requested by the client, see RFC 6960 section 4.2.2.3 last paragraph.
To make the additional responses optional (controlled by the client), 
a corresponding request extension could be defined. Hence that aspect 
could be covered by specifying a profile of the current OCSP protocol.

Cheers,
Niklas


On Fri 2019-10-25 at 08:57h, Dr. Pala wrote on pkix:
>Hi Peter,
>
>That is a great point. I would like to explore it with you.
>
>Yes, it is possible. However, I think that did not work for two 
>reasons. If I am not mistaken (please correct me if I am wrong), the 
>first reason is that the client has to explicitly request the 
>responses for the certificates in the chain (i.e., multiple requests). 
>The second reason, I think, is related to the trust model: the 
>responder have to sign responses from different CAs instead of just 
>one - so how can I trust the response from an intermediate CA to 
>guarantee me that all CAs above me (me included) are not revoked ? It 
>might work if you use a RootCA to sign the responses... but it is not 
>common to use the RootCA keys directly... In addition to that, each 
>certificate carries the indication where its revInfo can be retrieved, 
>therefore clients tend to make single requests to the different OCSP 
>responders one by one (it might be the same, but it might be 
>different). In addition to this, there might be implications about 
>pre-computed responses
>
>As far as I know, as you say, it is possible, but I have not seen 
>clients actually querying for multiple certificates - have you ?
>
>A different model would be for the OCSP responder to be able to 
>retrieve (maybe if requested by the client w/ an extension) the 
>additional responses (as the client do today) at regular intervals and 
>attach them together with the response for the request from the 
>client. This allows to have different validity period of the responses 
>and no real trust-related dependencies (i.e., the OCSP responder will 
>re-fetch the responses that are expired and maybe cache them for the 
>validity period or part of it).
>
>From a developer point of view, maybe this approach can provide easier 
>(for the developer) query mechanism (i.e., "What is the Revocation 
>Status of Certificate X ? Can you include the responses for the full 
>chain ?" instead of ""What is the Revocation Status of Certificate X, 
>Y, and Z ?" - not being sure if this is the right responder for all of 
>them)).
>
>Does that make sense ?
>
>Cheers,
>Max
>
>
>On 10/24/19 8:07 PM, Peter Gutmann wrote:
>>Dr. Pala <[email protected]> writes:
>>
>>>Providing Full Chain responses.
>>OCSP already does this, and has done since day 1.  That was the Identrus
>>value proposition, they would do all the checking for you and return
>>everything in a single response.  It proved... less than wildly popular.
>>
>>Peter.
>-- 
>Best Regards,
>Massimiliano Pala, Ph.D.
>OpenCA Labs Director
>OpenCA Logo

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

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