Please Review: required security algorithms for Java SE 7 implementations

Sean Mullan sean.mullan at
Tue Dec 28 07:41:45 PST 2010

I have posted the 3rd revision of the required algorithms list at:

Changes since the initial (00) version are:

- added MD5 and HmacMD5 to the required algorithms
- added the CertPath Encodings PKCS7 and PkiPath to the required algorithms
- specified that a TLSv1 implementation must also support the special signaling 
cipher suite TLS_EMPTY_RENEGOTIATION_INFO_SCSV for safe renegotiation (see RFC 5746)

Unless there are any further substantial comments, the plan is to proceed with 
this list for JDK 7.


On 12/15/10 10:11 AM, Sean Mullan wrote:
> Hello,
> Currently, the Java security APIs do not specify algorithm requirements for
> implementations of Java SE. This makes it difficult to develop conformance
> tests. Additionally, there is no guarantee that Java applications using these
> algorithms can inter-operate. See bug 5001004 for more information:
> We will be addressing this issue in Java SE 7 by defining a list of required
> algorithms that all implementations must support. This is the criteria we used
> to decide if an algorithm should be required:
> a) the algorithm is required by the JRE itself (ex: when validating signed jars)
> b) the algorithm is required by a higher level Java SE API such as JSSE/TLS or
> XML Signature
> c) the algorithm is in wide use
> Please review the following list:
> For each required algorithm, a corresponding section will be added to the API
> class summary of the applicable engine class. For example, for
>, the following paragraph will be added:
> Every implementation of the Java platform is required to support the
> following standard CertificateFactory type:
> * X.509
> This type is described in the CertificateFactory section of the Java
> Cryptography Architecture Standard Algorithm Names Document. Consult
> the release documentation for your implementation to see if any other
> types are supported.
> We are requesting feedback or any questions by December 22.
> Thanks,
> Sean

More information about the security-dev mailing list