Monday Apr 14, 2014

Version 5.0 of the Java Secure Coding Guidelines now available!

A new version of the Java Secure Coding Guidelines is now available at

This version has many updates, including:

  • Additional information for some of the new Java SE 8 features
  • Several new guidelines and examples
  • A new appendix covering the Java Native Interface
  • A new symbolic naming for sections
  • Several formatting changes
These guidelines contain coding patterns and best practices that are extremely useful for building robust and secure Java applications.

Thursday Mar 13, 2014

How to use the XML Signature secure validation mode

This post shows you how to use the new secure validation mode for XML Signatures that we introduced in JDK 7u25.[Read More]

Tuesday Dec 03, 2013

How to determine if a signed JAR is timestamped

Applying a timestamp when you sign a JAR is strongly recommended, as it allows you to prove that you signed the JAR during the time interval that your code signing certificate was still valid.[Read More]

Friday Nov 01, 2013

JEP 124: Enhance the Certificate Revocation-Checking API

JEP 124 (Enhance the Certificate Revocation-Checking API) is one of the 11 new security features in JDK 8. This feature enhances the API to support various revocation settings such as best-effort checking, end-entity certificate checking, and mechanism-specific options and parameters.[Read More]

Wednesday Sep 25, 2013

Slides for my JavaOne session: "Using the New JDK 8 Security Features"

Thanks to everyone who attended my talk yesterday on "Using the New JDK 8 Security Features". Here are the slides for my session for those that could not attend or would like a copy for further reference: CON_7932_Mullan.pdf.

Monday Aug 26, 2013

JEP 131: PKCS#11 Crypto Provider for 64-bit Windows

JEP 131 (PKCS#11 Crypto Provider for 64-bit Windows) is another of the 11 new security features funded and targeted to JDK 8.[Read More]

Monday Aug 19, 2013

JEP 130: SHA-224 Message Digests

JEP 130 (SHA-224 Message Digests) is one of the 11 new security features funded and targeted to JDK 8.[Read More]

Thursday Aug 15, 2013

I will be speaking at JavaOne 2013 on "Using the New JDK 8 Security Features"

I will be speaking at JavaOne 2013 on "Using the New JDK 8 Security Features"[Read More]

Friday Feb 12, 2010

Announcing XML Signature 1.1 and Signature Properties Last Call

The W3C XML Security Working Group has released a Last Call Working Draft for XML Signature 1.1:

An explanation of the changes against the XML Signature 1.0  specification is available:

Changes are focused on the set of mandatory to implement algorithms and markup for relevant key material.

The Working Group has also released a Last Call Working Draft for XML Signature Properties:

The Last Call period lasts until 18 March 2010; comments can be sent to public-xmlsec-comments @  The next step in the W3C Recommendation Track process is either a Candidate Recommendation phase to collect implementation experience, or another Working Draft.

The WG continues its work on XML Encryption 1.1 and is also working on a 2.0 version of Canonical XML and XML Signature.

Details on all the publications of the Working Group are available on  the Working Group Publication Status page at

Wednesday Jan 06, 2010

Secure Coding Guidelines for the Java Programming Language, Version 3.0

A new version (3.0) of the Secure Coding Guidelines for the Java Programming Language has just been published at

The secure coding guidelines documents best practices and patterns that you should adhere to when writing Java code in order to avoid vulnerabilities. These guidelines are important for every Java developer, whether you are writing a trusted library or an end-user application.

Version 3.0 is a significant enhancement and includes a new section on fundamentals as well as many new guidelines and enhancements.

Please send me any feedback you may have.

Thursday Oct 01, 2009

Using more recent Apache XML Security Libraries with JDK 6 or JDK 7

This question has come up in user forums quite a bit: "how can I use a more recent Apache XML Security library with the XML Signature APIs (JSR 105) in JDK 6 and JDK 7?"

Most of the time, you will not need to do this. Our JDK 6/7 XML Signature implementation is based on Apache XML Security and we try to keep up with the latest release. However, there may be a bug fix or new algorithm that you really need and are willing to depend on a more recent version of the Apache XML Security library that has that fix.  Here is what you need to do if so:

And that's it. You can also use the java.endorsed.dirs  system property to point to different directory containing the jars above.

Friday Jul 24, 2009

Using stronger XML Signature Algorithms in JDK 7

One of the new features of the XML Signature 1.1 specification, which is currently in draft review, is the addition of stronger cryptographic algorithms to the REQUIRED algorithms, such as the RSAwithSHA256 SignatureMethod algorithm. Additional RECOMMENDED and OPTIONAL algorithms have also been added. See section 6.1 for a complete list of algorithm requirements.

In JDK 7, you can already use many of these stronger XML Signature algorithms in your Java applications. The following algorithms are newly supported: the RSAwithSHA256, RSAwithSHA384, RSAwithSHA512 signature algorithms and the HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512 mac algorithms.

To take advantage of these stronger algorithms when generating XML Signatures, you may have to specify the URI of the algorithm (if there isn't a String constant already defined in the API). For example:

XMLSignatureFactory factory = XMLSignatureFactory.getInstance(); 
SignatureMethod sm = 
         (SignatureMethodParameterSpec) null);

No special code is required when validating XML Signatures with these algorithms as the implementation will automatically identify the algorithm URIs.

We plan to add String constants for these URIs in a future revision of the JSR 105 API, but for now you must specify the URIs when generating signatures.

Last, but not least, we are planning to backport support for these stronger signature and mac algorithms to JDK 6.

Friday May 29, 2009

Hope to see you at our Java Security BOF next week at JavaOne

Just a reminder that we'll be holding a BOF at this year's JavaOne conference on "New Security Features in JDK™ Releases 6 and 7".  It is on Wednesday at 6:45 PM in Gateway 102/103 in the Moscone Center. We plan to have a short presentation on the latest security features in JDK 6, JDK 7 and JavaFX. Then, we are going to show a demo of the new blacklist mechanism in the just-released JRE 6u14. The remaining time will be for Q&A so please bring your questions on Java Security as many members of Sun's Java Security team will be on hand to help answer them. 

Friday Apr 24, 2009

Come to our Java Security BOF at JavaOne 2009

We'll be holding a BOF at this year's JavaOne conference on "New Security Features in JDK™ Releases 6 and 7". This is sure to be an interesting BOF, as we'll go over all of the latest security features that we have added to JDK 6 and new ones that are targeted for JDK 7. We also plan to show a demo of some of the features. There should be plenty of time for Q&A so please bring your questions on Java Security as many members of Sun's Java Security team will be on hand to help answer them. 

I'll add more details as we get closer to JavaOne.

Friday Apr 03, 2009

New API to indicate the reason a certificate chain was invalid

In JDK 7, we have added a new method (getReason) to the class which returns an object indicating the reason a certificate chain, or CertPath, is invalid. Previously, there was no standard mechanism to determine the reason of failure, and applications had to depend on the exception message or the cause which could vary based on the underlying service provider implementation.

The getReason method returns an instance of CertPathValidatorException.Reason, which is an interface. There are 2 subclasses of this interface. One is BasicReason which is an enumeration of reasons which can apply to certificate chains of any type (X.509, PGP, etc). It contains reasons such as EXPIRED (certificate has expired) or INVALID_SIGNATURE. The other subclass is PKIXReason, and that enumerates the potential PKIX-specific reasons that an X.509 certification path may be invalid according to the PKIX (RFC 3280) standard, for example UNRECOGNIZED_CRIT_EXT . Here's an example of how you might use these new APIs in your application that validates certificate chains:

CertPathValidator cpv = CertPathValidator.getInstance("PKIX");
try {
    CertPathValidatorResult cpvr = cpv.validate(path, params);
} catch (CertPathValidatorException cpve) {
    CertPathValidator.Reason reason = cpve.getReason();
    int index = cpve.getIndex();
    System.err.println("Invalid certificate chain, certificate[" + index + "], reason: " + reason);⁞  


Sean Mullan


Top Tags
« April 2014