JDK-8337407 : Enhance OCSP, CRL and Certificate Fetch Timeouts
  • Type: CSR
  • Component: security-libs
  • Sub-Component: java.security
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 17-pool,17-pool-oracle
  • Submitted: 2024-07-29
  • Updated: 2025-01-08
  • Resolved: 2025-01-07
Related Reports
CSR :  
CSR :  
Relates :  
Description
Summary
-------
Allow the existing `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties to be specified in milliseconds by appending "ms" to the end of the numeric value.  In addition three new properties will be introduced.  The first is `com.sun.security.ocsp.readtimeout` which will provide a timeout specifically for the reading of an OCSP response after a connection has been established.  The other two properties are for certificate fetching timeouts based on an X.509 certificate's AIA extension: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout`. All three properties have the same syntax requirements as the existing timeout properties above.  The syntax specifics are detailed in the Solution section.

No changes from JDK 21, CSR JDK-8300722 except for the `com.sun.security.ocsp.readtimeout` property default value. `com.sun.security.ocsp.readtimeout` property default value should be aligned with the "com.sun.security.ocsp.timeout" property for backward compatibility.

Problem
-------
The existing property value must be a decimal integer to be interpreted in seconds.  Given the average latency for OCSP, certificate, and CRL fetches can be less than one second it is sensible to allow the user to specify a timeout period with millisecond granularity.  While OCSP and CRLs have timeout properties already, CA issuer certificate fetching can only be done through API calls and no System properties exist as they do for OCSP and CRL fetches.  This would introduce timeout properties that behave in a similar fashion to the OCSP and CRL timeout properties that prevent indefinite stalls during fetches.

Solution
--------

 - Enhance the allowed syntax for the existing `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` as detailed below.
 - Create three new properties `com.sun.security.ocsp.readtimeout`, `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` with the same syntax as those above.
   - `com.sun.security.ocsp.readtimeout` will hold the timeout value for reading an OCSP response after a connection has been established.  The `com.sun.security.crl.timeout` property will now handle only the timeout for establishing the TCP connection to the OCSP responder.  Previously the latter property's timeout value was applied to both kinds of timeouts.  This new property allows users to independently control the two kinds of timeouts similar to how other connect/read timeout property pairs are handled.
   - `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` handle timeouts for establishing the TCP connection and certificate reading, respectively, when following an X.509 certificate's AIA extension.

For all properties, existing and new, the proposed expanded syntax will conform to the following:

 - A decimal integer: This will maintain the existing behavior of being interpreted in seconds.  This ensures backward compatibility.  If a non-numeric or negative value is supplied, a default value will be applied.  The default value is also the current behavior.
 - A decimal integer ending in "s" (case-insensitive, no space) appended to it.  This will also be interpreted in seconds.
 - The user may specify a decimal integer value with "ms" (case-insensitive, no space) appended to it.  This will be interpreted by the OCSP or URICertStore subsystems as milliseconds.  For example, a value of "2500ms" will be a 2.5 second timeout.
 - As with the current behavior, non-numeric, non-decimal (e.g. hexadecimal values prepended by "0x", etc) values will be interpreted as illegal and the default value will be applied.  The same is true for negative values.
 - Whether the value is interpreted in seconds or milliseconds, a value of zero will disable the timeout.
 - For the newly proposed certificate fetching properties, the `com.sun.security.enableAIAcaIssuers` property must be set to true in order for fetching to occur and these property timeouts to be enabled.

### Default values

| Property Name | New? | Default value |
|:---|----|:---|
| `com.sun.security.crl.timeout` | No | 15 seconds (current value) |
| `com.sun.security.crl.readtimeout` | No | 15 seconds (current value) |
| `com.sun.security.ocsp.timeout` | No | 15 seconds (current value) |
| `com.sun.security.ocsp.readtimeout` | Yes | `com.sun.security.ocsp.timeout` (or its default) |
| `com.sun.security.cert.timeout` | Yes | 15 seconds |
| `com.sun.security.cert.readtimeout` | Yes | 15 seconds |
 
Specification
-------------
There are no specification changes since the classes that act upon these properties are not exported through the java.base module.


Comments
[~darcy] Yes, consider my approval granted.
07-01-2025

Moving to Approved. Note that having both "17-pool" and "17-pool-oracle" as fixVersion is not necessary -- just "17-pool" would suffice, but it is not incorrect and should be fine given the history here. [~jnimeh], I'm interpreting your comment https://bugs.openjdk.org/browse/JDK-8345114?focusedId=14734934&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14734934 as granting reviewer approval to the current state of this CSR. Thanks for the discussions.
07-01-2025

As discussed in https://bugs.openjdk.org/browse/JDK-8345114, JDK17 backport should address compatibility issue in addition to the original functionality
24-12-2024

I do not think it is necessary to upstream changes to 21 and up. Initially, this feature was introduced in the first release of jdk21, so it is OK have behavior changes between JDK versions
20-11-2024

I don't have a problem with the change, seems sensible. But now there will be a slight behavioral change from JDK mainline and the backports. I don't see the risk factor as significant, but should a bug be filed so the behavior is synchronized going forward?
19-11-2024

Hi [~fferrari] Thank you for the review and wording for the last section. It is much better.
14-11-2024

Hi [~abakhtin], It looks good to me. Personally, I would prefer something in line with the following for the last part of the "Solution" section, so we avoid repeating the syntax description. Solution -------- […] For all properties, existing and new, the proposed expanded syntax will conform to the following: - A decimal integer: This will maintain the existing behavior of being interpreted in seconds. This ensures backward compatibility. If a non-numeric or negative value is supplied, a default value will be applied. The default value is also the current behavior. - A decimal integer ending in "s" (case-insensitive, no space) appended to it. This will also be interpreted in seconds. - The user may specify a decimal integer value with "ms" (case-insensitive, no space) appended to it. This will be interpreted by the OCSP or URICertStore subsystems as milliseconds. For example, a value of "2500ms" will be a 2.5 second timeout. - As with the current behavior, non-numeric, non-decimal (e.g. hexadecimal values prepended by "0x", etc) values will be interpreted as illegal and the default value will be applied. The same is true for negative values. - Whether the value is interpreted in seconds or milliseconds, a value of zero will disable the timeout. - For the newly proposed certificate fetching properties, the `com.sun.security.enableAIAcaIssuers` property must be set to true in order for fetching to occur and these property timeouts to be enabled. ### Default values | Property Name | New? | Default value | |:---|----|:---| | `com.sun.security.crl.timeout` | No | 15 seconds (current value) | | `com.sun.security.crl.readtimeout` | No | 15 seconds (current value) | | `com.sun.security.ocsp.timeout` | No | 15 seconds (current value) | | `com.sun.security.ocsp.readtimeout` | Yes | `com.sun.security.ocsp.timeout` (or its default) | | `com.sun.security.cert.timeout` | Yes | 15 seconds | | `com.sun.security.cert.readtimeout` | Yes | 15 seconds |
14-11-2024

Moving to Provisional, not Approved. Will Approve only after more or more reviewers acknowledge the changes being made in the backport.
13-11-2024

[~jnimeh], [~fferrari], could you please look at the proposed changes for the CSR backport for JDK17. These changes address backward compatibilities for the default value of the com.sun.security.ocsp.readtimeout property.
13-11-2024

Thank you!
18-10-2024

Moving updated request to Approved; thanks.
18-10-2024

[~jnimeh], Thank you for review [~darcy], Could you please review the CSR as it was reviewed by engineers? Thank you.
14-10-2024

This is identical to the original, approved, CSR JDK-8300722. I also updated a few fields to match the original CSR (interface kind, compat risk, etc.)
08-10-2024

[~jnimeh], could you please review the CSR? It is identical to the CSR JDK-8300722 you submitted for JDK21
21-08-2024

Moving back to Draft. [~abakhtin], please have one or more engineers review this CSR before Proposing or (re)Finalizing it.
14-08-2024