Bonsoir,
Le jeudi 5 mars 2015 11:32:04 UTC+1, Jesus F a écrit :
> Look at RFC2560/6960 section A.1, describing the format of a request sent
> over HTTP:
>
> 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}
>
> That is, some characters from the base64 representation of the request are
> transformed:
> / is transformed into %2F
> + is transformed into %2B
> = is transformed into %3D
> and your OCSP responder is supposed to reverse that transformation (only
> once), then base-64 decode the string, and continue with the process (OCSP
> request parsing, etc).
>
> It seems your OCSP responder doesn't accept URL-encoded OCSP requests, or at
> least the "%2F".
>
> For exemple,
> http://ocsp.turktrust.com.tr/MG8wbTBGMEQwQjAJBgUrDgMCGgUABBQQ2AK0bL%2FGhSj1k0wefmhq3OpH2QQUm2YLShhBeYBnKwY4pSPDzSCPzccCCQFsT3pmwByBWqIjMCEwHwYJKwYBBQUHMAECBBIEEHVUJl9ozL9EVAJGSJJt7yA%3D
> gives a 400 error, and if I change "%2F" into "/", I get an OCSP response.
>
> May this can help you: I think this is the same error that Mr Erwann Abalea
> detected on this OCSP Responder in May 2012 (See "TURKTRUST Additional Root
> Inclusion Request" discussion).
That's right. The Base64 request MUST be URL-encoded, only once, and MUST be
URL-decoded, only once.
Volkan, Microsoft CAPI is an example of an OCSP client behaving that way.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
