[cabfpub] Non url-encoded OCSP requests using the GET method

[Erwann Abalea]

The encoding isn't done with a "%/" but a "%2F" (similarly, "+" is 
transformed into a "%2B", and "=" into a "%3D").

The best way to treat such input is to be liberal when receiving them: 
accept the request wether it's encoded or not (i.e. do your best to 
deliver a revocation status, even if the request is badly formatted). 
Since what is url-encoded is a base64 string, that's pretty easy to 
satisfy; just url-decode the request (just once), and try to 
de-base64-ify it. In that last step, if you receive characters that are 
not in the base64 charset, reject it. Some encoders can remove the 
trailing "=" characters, that's another check to do.

-- 
Erwann ABALEA

Le 31/03/2014 10:11, Mads Egil Henriksveen a écrit :
>
> Hi
>
> We have during the last months received a lot of OCSP requests using 
> the GET method where it is questionable whether they satisfy the 
> requirements or not.
>
> RFC 6960 states that:
>
>    An OCSP request using the GET method is constructed as follows:
>
>    GET {url}/{url-encoding of base-64 encoding of the DER encoding of
>
>    the OCSPRequest}
>
> The base-64 encoding may contain reserved characters like "/" and our 
> interpretation is that such reserved characters should be 
> percent-encoded (i.e. "%/") according to RFC 3986.
>
> However, we receive a lot of OCPS requests where this encoding 
> requirements are not satisfied, and we intend to start rejecting such 
> requests.
>
> Has anyone identified this as an issue and what should the recommended 
> behavior be in this case?
>
> Regards
>
> Mads
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140331/398e86f5/attachment-0003.html>