JDK-8287716 : Wrong implementation RFC 2560 in OCSP.java
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 17,23
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2022-06-01
  • Updated: 2024-09-08
  • Resolved: 2024-03-27
Related Reports
Duplicate :  
JDK-8328638 - Fallback option for POST-only OCSP requests
Relates :  
JDK-8179503 - Java should support GET OCSP calls
Description
ADDITIONAL SYSTEM INFORMATION :
All OS - All system -  Since Java 17

A DESCRIPTION OF THE PROBLEM :
Since jdk17 you implements the section A.1.1 from the RFC 2560. The RFC A.1.1 describe the request section as : To enable HTTP caching, small requests (that  after encoding are less than 255 bytes), MAY be submitted using GET. - So it's a recommendation not obligation.  But in the package java.base sun.security.provider.certpath.OCSP.java in the method getOCSPBytes line 225, the call to the GET is automatic if the request length after encoding is under or equal 255 bytes.
There is no possibility to use the POST request method if the request length is under or equal 255 bytes. So :
1: Put a flag to use POST method no matter the length of the request after encoding to respect the RFC 2560 section A.1.1.
2: For GET verb, put the condition to strictly test under 255 bytes not under or equal.
Thank you.
Comments
Resolving this as duplicate of JDK-8328638. Feel free to reopen if we want to do more followups.
27-03-2024
The JDK-8328638 has the next assumption: > So, to simplify migration, and to match the spirit of Postel's Law, it would be convenient to conditionalize JDK-8179503 with a flag, allowing users to fall back to old behavior to get over the compatibility bump while responders are being fixed up. So that new property is kind of workaround. Maybe it is possible to fix it in more general way, like allow to select the type per request and not globally, requesting of what types are supported by the responders, or fallback automatically/etc.
22-03-2024
[~serb] The PR for JDK-8328638 should address this by providing a system property to use POST instead of GET. So, I would like to close this as a duplicate, ok?
21-03-2024
The RFC 6960 was added later than RFC 5019, and it seems it relaxed the requirements, why the JDK should not follow it? ========= A.1. Request HTTP-based OCSP requests can use either the GET or the POST method to submit their requests. To enable HTTP caching, small requests (that after encoding are less than 255 bytes) MAY be submitted using GET. If HTTP caching is not important or if the request is greater than 255 bytes, the request SHOULD be submitted using POST. ========= https://datatracker.ietf.org/doc/html/rfc6960#appendix-A.1 >You have not included any rationale as to why this is important. Also, there is no requirement that implementations MUST support sending OCSP requests that are less than 255 bytes with POST. According to the description above the clients should use POST if "HTTP caching is not important", and that requests should be accepted. Let's re-evaluate this ticket.
20-03-2024
You have not included any rationale as to why this is important. Also, there is no requirement that implementations MUST support sending OCSP requests that are less than 255 bytes with POST. RFC 2560 and 6960 both state that "HTTP based OCSP requests can use either the GET or the POST method to submit their requests." The only recommendation is "If HTTP caching is not important, or the request is greater than 255 bytes, the request SHOULD be submitted using POST." Also, in general, where it helps improve performance and scalability, the JDK implementation also follows the guidelines in RFC 5019 which state: "The OCSP responder MUST support requests and responses over HTTP. When sending requests that are less than or equal to 255 bytes in total (after encoding) including the scheme and delimiters (http://), server name and base64-encoded OCSPRequest structure, clients MUST use the GET method (to enable OCSP response caching)." Closing this as Won't Fix.
06-06-2022
It looks like a functional bug. Moved to JDK for more evaluations.
02-06-2022