Re: Optimizing OCSP - Time for some spec work ?

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 ?

If the inclusion of the additional responses would encapsulate their 
authentication information, then we could trust those additional 
responses... otherwise, if not locally configured, the responder is not 
authoritative for other CAs. If your OCSP responder supports multiple 
CAs and could be authoritative for all of them... which certificate will 
your responder use to sign the response (i.e., shall it use the 
certificate that makes it authoritative for the requested certificate or 
the one that makes it authoritative for the issuing CA status ?)

Therefore, although it is technically possible, I think the way it is 
specified now it is not really usable. Do you know of implementation 
that use this feature? If so, do you know how they solved the Trust 
issue here ?

Ultimately, coming to using extensions in the requests - that is an 
interesting option (what about attaching the responses of the upper 
links in the chain as an extension in the basic response ?), however 
this complicates the implementation server-side ==> In general, whenever 
you add the possibility for the client to influence the content of the 
response, responses need to be generated according to the 
client-provided parameters, and, therefore, they cannot be pre-computed 
(which I think can be easily implemented if the number of target 
responses is sufficiently limited - i.e., your revoked certificates 
population is small enough that live responders calculate, cache, and 
update all responses 'live' with great performance and that do not 
require lots of resources).

Thanks again for the feedback!

Also, would you like to contribute to the effort shall we (IETF) decide 
to tackle this problem ?

Cheers,
Max

On 10/25/19 9:20 AM, Niklas Matthies wrote:
> 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
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

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