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

Specification

There are no specification changes since the classes that act upon these properties are not exported through the java.base module.