Subject: [pkix] url-encoding of OCSP HTTP GET requests (was Re: OCSP POST vs GET)

From: Bruce Stephens <[email-masked]>
Date: Thu, 13 Dec 2012 16:19:54 +0000

Erwann Abalea <[email-masked]> writes:

> The "malformedRequest" response is the 5 bytes response it received (the 5 at the end is the body size of the response).
>
> There's an extra leading '/' in the request. It may come from an extra trailing '/' at the OCSP URL. Check your certificates, read the authorityInfoAccess extension.
>
> RFC2560 states this:
>
> [...]
> GET {url}/{url-encoding of base-64 encoding of the DER encoding of
>    the OCSPRequest}
> [...]

Is the {url-encoding} part required by anybody? That is, if my
base64-encoded request is

 MEIwQDA+MDwwOjAJBgUrDgMCGgUABBRDjd0Ecx6qe7r2TYbGngjZE/bxaQQUj76OSES03/qykJF0zQNXx//ovQwCAWU=

my reading of appendix A of RFC 2560 suggests I ought to quote the
special characters (in particular / should be %2F, + should be
%2B). Verisign's OCSP responder seems OK with that, but also seems fine
without url-encoding.

However, http://seclab7.ncsl.nist.gov (the responder used for the NIST
PIV test cards) seems to reject url-encoded GET requests as
malformed. It responds to requests that are just base64 encoded (and
responds to HTTP POST as in the RFC).

Is that a bug in the responder (or is my url-encoding subtly wrong in
some way, though I'm using libcurl so I'm inclined to think it's
probably correct)? (I guess my real question is whether it's safer to
just ignore the RFC and remove the url-encoding call.)

[...]

---

From: Erwann Abalea <[email-masked]>
Date: Thu, 13 Dec 2012 18:47:29 +0100

Bonjour,

2012/12/13 Bruce Stephens <[email-masked]>

> > The "malformedRequest" response is the 5 bytes response it received (the
> 5 at the end is the body size of the response).
> >
> > There's an extra leading '/' in the request. It may come from an extra
> trailing '/' at the OCSP URL. Check your certificates, read the
> authorityInfoAccess extension.
> >
> > RFC2560 states this:
> >
> > [...]

During my tests of OCSP responders, I've come accross responders that
couldn't deal with non URL-encoded requests.
'/', '+', and '=' are classified as "reserved" characters by RFC2396, and
must be escaped (see 2.4, 2.4.2, 2.3).

> %2B). Verisign's OCSP responder seems OK with that, but also seems fine

A lot of well-behaving OCSP responders accept both forms.

> responds to HTTP POST as in the RFC).

That's a bug in the responder. RFC2398/2.4.2 is non ambiguous on this
point, an URI is always in escaped form, and as such MUST be unescaped
before being processed.
I hadn't played with this responder (because I don't have certificates to
test it), but you could try to only escape '+' and '=' characters, leaving
'/' intact.

Playing now with this responder shows abnormal behaviour. I alternatively
get different answers, with or without a request. With an empty request, I
could get 3 different answers (1 OCSP error and 2 different OCSP responses
for 2 different CAs).
I would not consider it representative of a good OCSP responder.

-- 
Erwann.