Once with TSIM 3.9.1 Service Pack 18, a new Java Version is delivered for AIX only, SR5 FP41 and with it, a higher security restriction.

A short snip from java.security is below. The complete java.security can be found attached.

#   KeySizeConstraint:
#     keySize Operator KeyLength
#       The constraint requires a key of a valid size range if the
#       "AlgorithmName" is of a key algorithm.  The "KeyLength" indicates
#       the key size specified in number of bits.  For example,
#       "RSA keySize <= 1024" indicates that any RSA key with key size less
#       than or equal to 1024 bits should be disabled, and
#       "RSA keySize < 1024, RSA keySize > 2048" indicates that any RSA key
#       with key size less than 1024 or greater than 2048 should be disabled.
#       This constraint is only used on algorithms that have a key size.
#
#   CAConstraint:
#     jdkCA
#       This constraint prohibits the specified algorithm only if the
#       algorithm is used in a certificate chain that terminates at a marked
#       trust anchor in the lib/security/cacerts keystore.  If the jdkCA
#       constraint is not set, then all chains using the specified algorithm
#       are restricted.  jdkCA may only be used once in a DisabledAlgorithm
#       expression.
#       Example:  To apply this constraint to SHA-1 certificates, include
#       the following:  "SHA1 jdkCA"
#
#   DenyAfterConstraint:
#     denyAfter YYYY-MM-DD
#       This constraint prohibits a certificate with the specified algorithm
#       from being used after the date regardless of the certificate's
#       validity.  JAR files that are signed and timestamped before the
#       constraint date with certificates containing the disabled algorithm
#       will not be restricted.  The date is processed in the UTC timezone.
#       This constraint can only be used once in a DisabledAlgorithm
#       expression.
#       Example:  To deny usage of RSA 2048 bit certificates after Feb 3 2020,
#       use the following:  "RSA keySize == 2048 & denyAfter 2020-02-03"
#
#   UsageConstraint:
#     usage [TLSServer] [TLSClient] [SignedJAR]
#       This constraint prohibits the specified algorithm for
#       a specified usage.  This should be used when disabling an algorithm
#       for all usages is not practical. 'TLSServer' restricts the algorithm
#       in TLS server certificate chains when server authentication is
#       performed. 'TLSClient' restricts the algorithm in TLS client
#       certificate chains when client authentication is performed.
#       'SignedJAR' constrains use of certificates in signed jar files.
#       The usage type follows the keyword and more than one usage type can
#       be specified with a whitespace delimiter.
#       Example:  "SHA1 usage TLSServer TLSClient"
# Note: The algorithm restrictions do not apply to trust anchors or
# self-signed certificates.

jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \
    RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224
    

    
    
# Algorithm restrictions for signed JAR files
#
# In some environments, certain algorithms or key lengths may be undesirable
# for signed JAR validation.  For example, "MD2" is generally no longer
# considered to be a secure hash algorithm
    
jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024
# Algorithm restrictions for Secure Socket Layer/Transport Layer Security
# (SSL/TLS) processing
# Disabled algorithms will not be negotiated for SSL/TLS connections, even
# if they are enabled explicitly in an application.
# For PKI-based peer authentication and key exchange mechanisms, this list
# of disabled algorithms will also be checked during certification path
# building and validation, including algorithms used in certificates, as
# well as revocation information such as CRLs and signed OCSP Responses.
# This is in addition to the jdk.certpath.disabledAlgorithms property above.

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, DESede, \
    EC keySize < 224, 3DES_EDE_CBC, anon, NULL

# Cryptographic Jurisdiction Policy defaults
#
# Import and export control rules on cryptographic software vary from
# country to country.  By default, the JDK provides two different sets of
# cryptographic policy files:
#
#     unlimited:  These policy files contain no restrictions on cryptographic
#                 strengths or algorithms.
#
#     limited:    These policy files contain more restricted cryptographic
#                 strengths, and are still available if your country or
#                 usage requires the traditional restrictive policy.

# 1.  If the Security property "crypto.policy" has been defined,
#     then the following mechanism is used:
#
#     The policy files are stored as jar files in subdirectories of
# <java-home>/lib/security/policy.  Each directory contains a complete
# set of policy files.
#
#     The "crypto.policy" Security property controls the directory
#     selection, and thus the effective cryptographic policy.
#
# The default set of directories is:
#
#     limited | unlimited
#
# 2.  If the "crypto.policy" property is not set and the traditional
#     US_export_policy.jar and local_policy.jar files
#     (e.g. limited/unlimited) are found in the legacy
#     <java-home>/lib/security directory, then the rules embedded within
#     those jar files will be used. This helps preserve compatibility
# for users upgrading from an older installation.
#
# 3.  If the jar files are not present in the legacy location
#     and the "crypto.policy" Security property is not defined,
#     then the JDK will use the unlimited settings (equivalent to
#     crypto.policy=unlimited)

# To select unlimited cryptographic strength as defined in these two files 
# set crypto.policy = unlimited in the file <java_home>/conf/security/java.security.
# To set up restrictions to cryptographic strength that are different than the 
# settings in the policy files in the limited or unlimited directory, you can create
# a new directory, parallel with limited and unlimited, and place your policy files
# there. For example, you may create a directory called custom. In this custom
# directory you include the files default_*export.policy and/or exempt_*local.policy.

# To select cryptographic strength as defined in the files in the custom directory,
# set crypto.policy = custom in the file <java_home>/conf/security/java.security.