Hi Ryan, thank you for the clarification. I have seen such GET-requests on our openca-ocspd as well. The client has added another slash (which ended up in the path string on the server), but more severely, the GET-request was not url-encoded, so further slashes inside the base64-encoded request caused additional trouble. I could fix this in the source of the ocspd. The client was a Mac in this case. To my impression the various implementations for sending GET-requests need some improvements. I fully agree that your recommendation to avoid trailing slashes may help people to ship around these bad implementations. But since I have hit this problem, too, I was interested in your feedback how you understand the RFC's.
Thank you and best regards, Martin On 13.12.2013 17:28, Ryan Castellucci wrote: > As I mentioned in the comments I included, a trailing slash, while > totally *valid*, causes problems with MS-CAPI. MS-CAPI likes to use > HTTP GET for its OCSP requests, and it seems to like to add an extra > slash even if it's not needed. I'm not finding anything online > documenting this online, but have a look at some certificates from > commercial CAs - none of them have trailing slashes. I'll dig up some > request logs from my server that show the problem. > > On Fri, Dec 13, 2013 at 5:20 AM, Martin Hecht wrote: >> Hi, >> >> shouldn't the trailing slash be allowed? In RFC 2560 section 3.1 it reads: >> The value of the accessLocation field in the subject certificate defines >> the transport (e.g. HTTP) used to access the OCSP responder and may >> contain other transport dependent information (e.g. a URL). >> >> and in the references (section 6) RFC 1738 is mentioned for [URL], and >> there, in section 3.3 "HTTP" it reads: >> An HTTP URL takes the form: >> http://<host>:<port>/<path>?<searchpart> >> [...] If neither <path> nor <searchpart> is present, the "/" may also >> be omitted. >> >> To my understanding there is nothing wrong, if there is a trailing >> (single) slash. It is the separator between <host> with (optional) >> :<port> and an empty <path> value. It MAY be omitted, but it may also be >> there, right? >> >> Please correct me if I am missing something. >> >> best regards, >> Martin >> >> >> On 10.12.2013 01:34, Ryan Castellucci wrote: >>> I've discovered that having a trailing slash in an OCSP URL can cause >>> problems with MS-CAPI. This is a minimal patch to make the example >>> non-broken. I haven't added any additional text to the documentation >>> to explain this because all that was there in the first place was the >>> example. Please let me know if this needs to be more extensively >>> documented. >>> >>> I've CC'd cr...@bis.doc.gov is requested in the readme, however this >>> is a trivial documentation change which doesn't touch any encryption >>> code. >>> >>> diff --git a/doc/apps/x509v3_config.pod b/doc/apps/x509v3_config.pod >>> index 06d8467..8e3d48a 100644 >>> --- a/doc/apps/x509v3_config.pod >>> +++ b/doc/apps/x509v3_config.pod >>> @@ -220,7 +220,7 @@ certain values are meaningful, for example OCSP >>> and caIssuers. >>> >>> Example: >>> >>> - authorityInfoAccess = OCSP;URI:http://ocsp.my.host/ >>> + authorityInfoAccess = OCSP;URI:http://ocsp.my.host >>> authorityInfoAccess = caIssuers;URI:http://my.ca/ca.html >>> ______________________________________________________________________ >>> OpenSSL Project http://www.openssl.org >>> Development Mailing List openssl-dev@openssl.org >>> Automated List Manager majord...@openssl.org > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
