Standard Names

The Java SE Security API requires and uses a set of standard names for algorithms, certificate and keystore types.

In some cases naming conventions are given for forming names that are not explicitly listed, to facilitate name consistency across provider implementations. Items in angle brackets (such as <digest> and <encryption>) are placeholders to be replaced by a specific message digest, encryption algorithm, or other name.

Note: Standard names are not case-sensitive.

AlgorithmParameterGenerator Algorithms

The algorithm names in this section can be specified when generating an instance of AlgorithmParameterGenerator.

Algorithm Name

Description

DiffieHellman

Parameters for use with the Diffie-Hellman algorithm.

DSA

Parameters for use with the Digital Signature Algorithm.

AlgorithmParameters Algorithms

The algorithm names in this section can be specified when generating an instance of AlgorithmParameters.

Algorithm Name

Description

AES

Parameters for use with the AES algorithm.

Blowfish

Parameters for use with the Blowfish algorithm.

DES

Parameters for use with the DES algorithm.

DESede

Parameters for use with the DESede algorithm.

DiffieHellman

Parameters for use with the DiffieHellman algorithm.

DSA

Parameters for use with the Digital Signature Algorithm.

EC

Parameters for use with the EC algorithm.

OAEP

Parameters for use with the OAEP algorithm.

PBEWith<digest>And<encryption>

Parameters for use with the PBEWith<digest>And<encryption> algorithm. Examples: PBEWithMD5AndDES, and PBEWithHmacSHA256AndAES.

PBE

Parameters for use with the PBE algorithm. This name should not be used, in preference to the more specific PBE-algorithm names previously listed.

RC2

Parameters for use with the RC2 algorithm.

CertificateFactory Types

The type in this section can be specified when generating an instance of CertificateFactory.

CertPath Encodings

The following encodings may be passed to the getEncoded method of CertPath or the generateCertPath(InputStream inStream, String encoding) method of CertificateFactory.

Encoding

Description

PKCS7

A PKCS#7 SignedData object, with the only significant field being certificates. In particular, the signature and the contents are ignored. If no certificates are present, a zero-length CertPath is assumed.

Warning: PKCS#7 does not maintain the order of certificates in a certification path. This means that if a CertPath is converted to PKCS#7 encoded bytes and then converted back, the order of the certificates may change, potentially rendering the CertPath invalid. Users should be aware of this behavior.

Within the sequence, the order of certificates is such that the subject of the first certificate is the issuer of the second certificate, and so on. Each certificate in PkiPath shall be unique. No certificate may appear more than once in a value of Certificate in PkiPath. The PkiPath format is defined in defect report 279 against X.509 (2000) and is incorporated into Technical Corrigendum 1 (DTC 2) for the ITU-T Recommendation X.509 (2000). See the ITU web site for details.

CertPathBuilder Algorithms

The algorithm in this section can be specified when generating an instance of CertPathBuilder.

Algorithm Name

Description

PKIX

The PKIX certification path validation algorithm as defined in the ValidationAlgorithm service attribute. The output of CertPathBuilder instances implementing this algorithm is a certification path validated against the PKIX validation algorithm.

CertPathValidator Algorithms

The algorithm in this section can be specified when generating an instance of CertPathValidator.

CertStore Types

The type in this section can be specified when generating an instance of CertStore.

Type

Description

Collection

A CertStore implementation that retrieves certificates and CRLs from a Collection. This type of CertStore is particularly useful in applications where certificates or CRLs are received in a bag or some sort of attachment, such as with a signed email message or in an SSL negotiation.

LDAP

A CertStore implementation that fetches certificates and CRLs from an LDAP directory using the schema defined in the LDAPSchema service attribute.

Cipher Algorithm Names

The following names can be specified as the algorithm component in a transformation when requesting an instance of Cipher.

Algorithm Name

Description

AES

Advanced Encryption Standard as specified by NIST in FIPS 197. Also known as the Rijndael algorithm by Joan Daemen and Vincent Rijmen, AES is a 128-bit block cipher supporting keys of 128, 192, and 256 bits.

To use the AES cipher with only one valid key size, use the format AES_<n>, where <n> can be 128, 192 or 256.

Triple DES Encryption (also known as DES-EDE, 3DES, or Triple-DES). Data is encrypted using the DES algorithm three separate times. It is first encrypted using the first subkey, then decrypted with the second subkey, and encrypted with the third subkey.

Using modes such as CFB and OFB, block ciphers can encrypt data in units smaller than the cipher's actual block size. When requesting such a mode, you may optionally specify the number of bits to be processed at a time by appending this number to the mode name as shown in the "DES/CFB8/NoPadding" and "DES/OFB32/PKCS5Padding" transformations. If no such number is specified, a provider-specific default is used. (For example, the SunJCE provider uses a default of 64 bits for DES.) Thus, block ciphers can be turned into byte-oriented stream ciphers by using an 8-bit mode such as CFB8 or OFB8.

CTR

A simplification of OFB, Counter mode updates the input block as a counter.

CTS

Cipher Text Stealing, as described in Bruce Schneier's book Applied Cryptography-Second Edition, John Wiley and Sons, 1996.

ECB

Electronic Codebook Mode, as defined in FIPS PUB 81 (generally this mode should not be used for multiple blocks of data).

Using modes such as CFB and OFB, block ciphers can encrypt data in units smaller than the cipher's actual block size. When requesting such a mode, you may optionally specify the number of bits to be processed at a time by appending this number to the mode name as shown in the "DES/CFB8/NoPadding" and "DES/OFB32/PKCS5Padding" transformations. If no such number is specified, a provider-specific default is used. (For example, the SunJCE provider uses a default of 64 bits for DES.) Thus, block ciphers can be turned into byte-oriented stream ciphers by using an 8-bit mode such as CFB8 or OFB8.

Optimal Asymmetric Encryption. Padding scheme defined in PKCS1, where <digest> should be replaced by the message digest and <mgf> by the mask generation function. Examples: OAEPWithMD5AndMGF1Padding and OAEPWithSHA-512AndMGF1Padding.

If OAEPPadding is used, Cipher objects are initialized with a javax.crypto.spec.OAEPParameterSpec object to supply values needed for OAEPPadding.

The size of an instance of a GenericBlockCipher must be a multiple of the block cipher's block length. The padding length, which is always present, contributes to the padding, which implies that if:

sizeof(content) + sizeof(MAC) % block_length = 0,

padding has to be (block_length - 1) bytes long, because of the existence of padding_length.

This makes the padding scheme similar (but not quite) to PKCS5Padding, where the padding length is encoded in the padding (and ranges from 1 to block_length). With the SSL scheme, the sizeof(padding) is encoded in the always present padding_length and therefore ranges from 0 to block_length-1.

Configuration Types

The type in this section can be specified when generating an instance of javax.security.auth.login.Configuration.

Type

Description

JavaLoginConfig

The default Configuration implementation from the SUN provider, as described in the [Configuration class specification] (../../api/javax/security/auth/login/Configuration.html). This type accepts java.security.URIParameter as a valid Configuration.Parameter type. If this parameter is not specified, then the configuration information is loaded from the sources described in the ConfigFile class specification. If this parameter is specified, the configuration information is loaded solely from the specified URI.

Exemption Mechanisms

The following exemption mechanism names can be specified in the permission policy file that accompanies an application considered "exempt" from cryptographic restrictions.

Algorithm Name

Description

KeyEscrow

An encryption system with a backup decryption capability that allows authorized persons (users, officers of an organization, and government officials), under certain prescribed conditions, to decrypt ciphertext with the help of information supplied by one or more trusted parties who hold special data recovery keys.

KeyRecovery

A method of obtaining the secret key used to lock encrypted data. One use is as a means of providing fail-safe access to a corporation's own encrypted information in times of disaster.

KeyWeakening

A method in which a part of the key can be escrowed or recovered.

GSSAPI Mechanisms

The following mechanisms can be specified when using GSSAPI. Note that Object Identifiers (OIDs) are specified instead of names to be consistent with the GSSAPI standard.

Elliptic Curve Diffie-Hellman as defined in ANSI X9.63 and as described in RFC 3278: "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)."

ECMQV

Elliptic Curve Menezes-Qu-Vanstone.

KeyFactory Algorithms

The algorithm names in this section can be specified when generating an instance of KeyFactory.

(Except as noted, these classes create keys for which Key.getAlgorithm() returns the standard algorithm name.)

Algorithm Name

Description

DiffieHellman

Keys for the Diffie-Hellman KeyAgreement algorithm.

Note:key.getAlgorithm() will return "DH" instead of "DiffieHellman".

DSA

Keys for the Digital Signature Algorithm.

EC

Keys for the Elliptic Curve algorithm.

RSA

Keys for the RSA algorithm (Signature/Cipher).

KeyGenerator Algorithms

The following algorithm names can be specified when requesting an instance of KeyGenerator.

Algorithm Name

Description

AES

Key generator for use with the AES algorithm.

ARCFOUR

Key generator for use with the ARCFOUR (RC4) algorithm.

Blowfish

Key generator for use with the Blowfish algorithm.

DES

Key generator for use with the DES algorithm.

DESede

Key generator for use with the DESede (triple-DES) algorithm.

HmacMD5

Key generator for use with the HmacMD5 algorithm.

HmacSHA1
HmacSHA224
HmacSHA256
HmacSHA384
HmacSHA512

Keys generator for use with the various flavors of the HmacSHA algorithms.

RC2

Key generator for use with the RC2 algorithm.

KeyManagerFactory Algorithms

The algorithm names that can be specified when generating an instance of KeyManagerFactory.

Algorithm Name

Description

PKIX

A factory for X509ExtendedKeyManagers that manage X.509 certificate-based key pairs for local side authentication according to the rules defined by the IETF PKIX working group in RFC 5280 or its successor. The KeyManagerFactory must support initialization using the class javax.net.ssl.KeyStoreBuilderParameters.

KeyPairGenerator Algorithms

The algorithm names that can be specified when generating an instance of KeyPairGenerator.

(Except as noted, these classes create keys for which Key.getAlgorithm() returns the standard algorithm name.)

Algorithm Name

Description

DiffieHellman

Generates keypairs for the Diffie-Hellman KeyAgreement algorithm.

Note:key.getAlgorithm() will return "DH" instead of "DiffieHellman".

DSA

Generates keypairs for the Digital Signature Algorithm.

RSA

Generates keypairs for the RSA algorithm (Signature/Cipher).

EC

Generates keypairs for the Elliptic Curve algorithm.

KeyStore Types

The types in this section can be specified when generating an instance of KeyStore.

Type

Description

jceks

The proprietary keystore implementation provided by the SunJCE provider.

jks

The proprietary keystore implementation provided by the SUN provider.

dks

A domain keystore is a collection of keystores presented as a single logical keystore. It is specified by configuration data whose syntax is described in the DomainLoadStoreParameter class.

pkcs11

A keystore backed by a PKCS #11 token.

pkcs12

The transfer syntax for personal identity information as defined in PKCS #12.

Mac Algorithms

The following algorithm names can be specified when requesting an instance of Mac.

Hash algorithms defined in FIPS PUB 180-4. Secure hash algorithms - SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256 - for computing a condensed representation of electronic data (message). When a message is input to a hash algorithm, the result is an output called a message digest. A message digest ranges in length from 160-512 bits, depending on the algorithm.

SHA3-224
SHA3-256
SHA3-384
SHA3-512

Permutation-based hash and extendable-output functions as defined in FIPS PUB 202. An input message length can vary; the length of the output digest is fixed.

Policy Types

The type in this section can be specified when generating an instance of Policy.

Type

Description

JavaPolicy

The default Policy implementation from the SUN provider, as described in the Policy File guide. This type accepts java.security.URIParameter as a valid Policy.Parameter type. If this parameter is not specified, then the policy information is loaded from the sources described in the Default Policy File Locations section of the PolicyFile guide. If this parameter is specified, the policy information is loaded solely from the specified URI.

SaslClient Mechanisms

The mechanisms in this section can be specified when generating an instance of SaslClient.

An algorithm supplied by the SUN provider using DRBG mechanisms as defined in NIST SP 800-90Ar1.

SHA1PRNG

The name of the pseudo-random number generation (PRNG) algorithm supplied by the SUN provider. This algorithm uses SHA-1 as the foundation of the PRNG. It computes the SHA-1 hash over a true-random seed value concatenated with a 64-bit counter which is incremented by 1 for each operation. From the 160-bit SHA-1 output, only 64 bits are used.

Windows-PRNG

Obtains random numbers from the underlying Windows OS.

Service Attributes

The attributes in this section are for cryptographic services. The service attributes can be used as filters for selecting providers.

A cryptographic service is always associated with a particular algorithm or type. For example, a digital signature service is always associated with a particular algorithm (for example, DSA), and a CertificateFactory service is always associated with a particular certificate type (for example, X.509).

Note: The attribute name and value are case-insensitive.

Attribute

Description

KeySize

The maximum key size that the provider supports for the cryptographic service.

ImplementedIn

Whether the implementation for the cryptographic service is done by software or hardware. The value of this attribute is "software" or "hardware".

ValidationAlgorithm

The name of the specification that defines the certification path validation algorithm that an implementation of CertPathBuilder or CertPathValidator supports. RFCs should be specified as "RFC#" (ex: "RFC5280") and Internet Drafts as the name of the draft (ex: "draft-ietf-pkix-rfc2560bis-01.txt"). Values for this attribute that are specified as selection criteria to the Security.getProviders method will be compared using the String.equalsIgnoreCase method. All PKIX implementations of CertPathBuilder and CertPathValidator should provide a value for this attribute.

LDAPSchema

The name of the specification that defines the LDAP schema that an implementation of an LDAP CertStore uses to retrieve certificates and CRLs. The format and semantics of this attribute is the same as described for the ValidationAlgorithm attribute. All LDAP implementations of CertStore should provide a value for this attribute.

The DSA signature algorithms as defined in FIPS PUB 186-2 and 186-3 with an output as defined in IEEE P1363 format. The format of the Signature bytes for these algorithms is an ASN.1 encoded sequence of the integers r and s:

The ECDSA signature algorithms as defined in ANSI X9.62 with an output as defined in IEEE P1363 format. The format of the Signature bytes for these algorithms is an ASN.1 encoded sequence of the integers r and s:

SEQUENCE ::= { r INTEGER, s INTEGER }

<digest>with<encryption>

Use this to form a name for a signature algorithm with a particular message digest (such as MD2 or MD5) and algorithm (such as RSA or DSA), just as was done for the explicitly defined standard names in this section (MD2withRSA, and so on).

For the signature schemes defined in PKCS #1 v 2.0, for which the <digest>with<encryption> form is insufficient, <digest>with<encryption>and<mgf> can be used to form a name. Here, <mgf> should be replaced by a mask generation function such as MGF1. Example: MD5withRSAandMGF1

For the signature formats defined in IEEE P1363, <digest>with<encryption>in<format>Format can be used to form a name. Example: SHA1withECDSAinP1363Format

SSLContext Algorithms

The algorithm names in this section can be specified when generating an instance of SSLContext.

TrustManagerFactory Algorithms

The algorithm name in this section can be specified when generating an instance of TrustManagerFactory.

Algorithm Name

Description

PKIX

A factory for X509ExtendedTrustManager objects that validate certificate chains according to the rules defined by the IETF PKIX working group in RFC 5280 or its successor. The TrustManagerFactory must support initialization using the class javax.net.ssl.CertPathTrustManagerParameters.

The mechanism that can be specified when generating an instance of XMLSignatureFactory, KeyInfoFactory, or TransformService.

The mechanism identifies the XML processing mechanism that an implementation uses internally to parse and generate XML signature and KeyInfo structures. Also, note that each TransformService instance supports a specific transform algorithm in addition to a mechanism. The standard names for the transform algorithms are defined in the next section.

Mechanism

Description

DOM

The Document Object Model.

XML Signature Transform (TransformService) Algorithms

The algorithms in this section can be specified when generating an instance of TransformService.

Note: The URIs are specified instead of names have to be consistent with the XML Signature standard. API constants have been defined for each URIs, and are listed in parentheses after each URI in the following table.

JSSE Cipher Suite Names

The following table contains the standard JSSE cipher suite names. Over time, various groups have added additional cipher suites to the SSL/TLS/DTLS namespace.

Some JSSE cipher suite names were defined before TLSv1.0 was finalized, and were therefore given the SSL_ prefix. The names mentioned in the TLS RFCs prefixed with TLS_ are functionally equivalent to the JSSE cipher suites prefixed with SSL_.

Additional JSSE Standard Names

The keyType parameter passed to the chooseClientAlias, chooseServerAlias, getClientAliases, and getServerAliases methods of X509KeyManager specifies the public key types.

Each row of the table that follows lists the standard name that should be used for keyType, given the specified certificate type.

Standard Names for a Certificate Type

Name

Certificate Type

RSA

RSA

DSA

DSA

DH_RSA

Diffie-Hellman with RSA signature

DH_DSA

Diffie-Hellman with DSA signature

EC

Elliptic Curve

EC_EC

Elliptic Curve with ECDSA signature

EC_RSA

Elliptic Curve with RSA signature

The protocols parameter passed to the setEnabledProtocols method of SSLSocket and SSLEngine specifies the protocol versions to be enabled for use on the connection. The table that follows lists the standard names that can be passed to setEnabledProtocols or that may be returned by the SSLSocket and SSLEnginegetSupportedProtocols and getEnabledProtocols methods.

The protocols parameter returned from the getProtocol method in SSLSession. The protocols parameter passed to the setProtocols method of SSLParameters or that may be returned by the getProtocols method of SSLParameters.

Currently, the SSLv3, TLSv1, and TLSv1.1 protocols allow you to send SSLv3, TLSv1, and TLSv1.1 hellos encapsulated in an SSLv2 format hello. For more details on the reasons for allowing this compatibility in these protocols, see Appendix E in the appropriate RFCs (previously listed).

Note: Some SSL/TLS servers do not support the v2 hello format and require that client hellos conform to the SSLv3 or TLSv1 client hello formats.

The SSLv2Hello option controls the SSLv2 encapsulation. If SSLv2Hello is disabled on the client, then all outgoing messages will conform to the SSLv3/TLSv1 client hello format. If SSLv2Hello is disabled on the server, then all incoming messages must conform to the SSLv3/TLSv1 client hello format.

The authType parameter passed to the checkClientTrusted and checkServerTrusted methods of X509TrustManager indicates the authentication type. The table that follows specifies what standard names should be used for the client or server certificate chains.

Standard Names for Client or Server Certificate Chain

Client or Server Certificate Chain

Authentication Type Standard Name

Client

Determined by the actual certificate used. For instance, if RSAPublicKey is used, the authType should be "RSA".

Server

The key exchange algorithm portion of the cipher suites represented as a String, such as "RSA" or "DHE_DSS".

Note: For some exportable cipher suites, the key exchange algorithm is determined at runtime during the handshake.

For instance, for TLS_RSA_EXPORT_WITH_RC4_40_MD5, the authType should be "RSA_EXPORT" when an ephemeral RSA key is used for the key exchange, and "RSA" when the key from the server certificate is used. Or it can take the value "UNKNOWN".

Endpoint identification algorithm indicates the endpoint identification or verification procedures during SSL/TLS/DTLS handshaking. The algorithm name can be passed to the setEndpointIdentificationAlgorithm() method of javax.net.ssl.SSLParameters.

Security Algorithm Specification

This section specifies details concerning some of the algorithms defined in this document. Any provider supplying an implementation of the listed algorithms must comply with the specifications in this section.

Specification Template

The following table shows the fields of the algorithm specifications.

Field

Description

Name

The name by which the algorithm is known. This is the name passed to the getInstance method (when requesting the algorithm), and returned by the getAlgorithm method to determine the name of an existing algorithm object. These methods are in the relevant engine classes: Signature, MessageDigest, KeyPairGenerator, and AlgorithmParameterGenerator .

Type

The type of algorithm: Signature, MessageDigest, KeyPairGenerator, or AlgorithmParameterGenerator.

Description

General notes about the algorithm, including any standards implemented by the algorithm, applicable patents, and so on.

KeyPair Algorithm (optional)

The KeyPair algorithm for this algorithm.

Keysize (optional)

For a keyed algorithm or key generation algorithm: the valid keysizes.

Size (optional)

For an algorithm parameter generation algorithm: the valid "sizes" for algorithm parameter generation.

Parameter Defaults (optional)

For a key generation algorithm: the default parameter values.

Signature Format (optional)

For a Signature algorithm, the format of the signature, that is, the input and output of the verify and sign methods, respectively.

Algorithm Specifications

SHA-1 Message Digest Algorithm

Field

Description

Name

SHA-1

Type

MessageDigest

Description

The message digest algorithm as defined in FIPS 180-4. The output of this algorithm is a 160-bit digest.

SHA-224 Message Digest Algorithm

Field

Description

Name

SHA-224

Type

MessageDigest

Description

The message digest algorithm as defined in FIPS 180-4. The output of this algorithm is a 224-bit digest.

SHA-256 Message Digest Algorithm

Field

Description

Name

SHA-256

Type

MessageDigest

Description

The message digest algorithm as defined in FIPS 180-4. The output of this algorithm is a 256-bit digest.

SHA-384 Message Digest Algorithm

Field

Description

Name

SHA-384

Type

MessageDigest

Description

The message digest algorithm as defined in FIPS 180-4. The output of this algorithm is a 384-bit digest.

SHA-512 Message Digest Algorithm

Field

Description

Name

SHA-512

Type

MessageDigest

Description

The message digest algorithm as defined in FIPS 180-4. The output of this algorithm is a 512-bit digest.

SHA3-224 Message Digest Algorithms

Field

Description

Name

SHA3-224

Type

MessageDigest

Description

The message digest algorithm as defined in FIPS PUB 202. The output of this algorithm is a 224-bit digest.

SHA3-256 Message Digest Algorithms

Field

Description

Name

SHA3-256

Type

MessageDigest

Description

The message digest algorithm as defined in FIPS PUB 202. The output of this algorithm is a 256-bit digest.

SHA3-384 Message Digest Algorithms

Field

Description

Name

SHA3-384

Type

MessageDigest

Description

The message digest algorithm as defined in FIPS PUB 202. The output of this algorithm is a 384-bit digest.

SHA3-512 Message Digest Algorithms

Field

Description

Name

SHA3-512

Type

MessageDigest

Description

The message digest algorithm as defined in FIPS PUB 202. The output of this algorithm is a 512-bit digest.

MD2 Message Digest Algorithm

Field

Description

Name

MD2

Type

MessageDigest

Description

The message digest algorithm as defined in RFC 1319. The output of this algorithm is a 128-bit digest.

MD5 Message Digest Algorithm

Field

Description

Name

MD5

Type

MessageDigest

Description

The message digest algorithm as defined in RFC 1321. The output of this algorithm is a 128-bit digest.

This algorithm is the key pair generation algorithm described in PKCS #1.

Strength

The length, in bits, of the modulus n. This must be a multiple of 8 that is greater than or equal to 512

DSA Parameter Generation Algorithm

Field

Description

Names

DSA

Type

AlgorithmParameterGenerator

Description

This algorithm is the parameter generation algorithm described in NIST FIPS 186 for DSA.

Strength

The length, in bits, of the modulus p. This must be a multiple of 64, ranging from from 512 to 1024 (inclusive), 2048, or 3072.
Alternatively, generate DSA parameters with the DSAGenParameterSpec class. Note that this class supports the latest version of DSA standard, FIPS PUB 186-3, and only allows certain length of prime P and Q to be used. Valid sizes for length of prime P and sub-prime Q in bits are as follows:

(1024, 160)
(2048, 224)
(2048, 256)
(3072, 256)

Security Algorithm Implementation Requirements

This section defines the security algorithm requirements for JDK 9 implementations. The security algorithm requirements for JDK 9 implementations are intended to improve the interoperability of JDK 9 implementations and applications that use these algorithms.

Note: The requirements in this section are not a measure of the strength or security of the algorithm. For example, recent advances in cryptanalysis have found weaknesses in the strength of the MD5 message digest algorithm. It is your responsibility to determine whether the algorithm meets the security requirements of your application.

Every implementation of the JDK 9 platform must support the specified algorithms in the table that follows. These requirements do not apply to 3rd party providers. Consult the release documentation for your implementation to see if any other algorithms are supported.

Class

Algorithm Name(s)

AlgorithmParameterGenerator
Implementations must support the key sizes
in parentheses.

DiffieHellman (1024, 2048)
DSA (1024, 2048)

AlgorithmParameters

AES
DES
DESede
DiffieHellman
DSA

CertificateFactory

X.509

CertPath Encoding

PKCS7
PkiPath

CertPathBuilder

PKIX

CertPathValidator

PKIX

CertStore

Collection

Cipher
The algorithms are specified as transformations in getInstance. Implementations must support the key sizes in parentheses.

[1] No specific Configuration type, Policy type or SecureRandom algorithm is required; however, an implementation-specific default must be provided.

XML Signature Algorithms

Every implementation of the JDK 9 platform must support the specified XML Signature algorithms in the table that follows. These requirements do not apply to 3rd party providers. Consult the release documentation for your implementation to see if any other algorithms are supported.