Sean Mullan's Blog

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 = 
    factory.newSignatureMethod
        ("http://www.w3.org/2001/04/xmldsig-more#rsa-sha256", 
         (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.

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.

In JDK 7, we have added a new method (getReason) to the java.security.cert.CertPathValidatorException 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);⁞  
}

There is a new CertificateRevocationException class in JDK 7 in the java.security.cert package that indicates that an X.509 certificate is revoked and also allows you to determine additional information such as the reason the certificate has been revoked and when it was revoked.  The getRevocationReason method returns a CRLReason, which is a new enum class that enumerates the different reasons an X.509 certificate can be revoked, such as compromise of the private key. In JDK 7, The Sun PKIX CertPathValidator service provider implementation has been enhanced to throw this exception. Here's an example of how your application may use this new exception class:

CertPathValidator cpv = CertPathValidator.getInstance("PKIX", "Sun");
try {
    CertPathValidatorResult cpvr = cpv.validate(path, params);
} catch (CertPathValidatorException cpve) {
    if (cpve.getCause() instanceof CertificateRevokedException) {
        CertificateRevokedExcepion cre = (CertificateRevokedException) cpve.getCause();
        System.err.println("Certificate  revoked on " + cre.getRevocationDate());
        System.err.println("reason  for revocation: " + cre.getCRLReason());
    }
}

Hello everyone. Although I have been with Sun for over 10 years, this is my first blog entry at blogs.sun.com. I already have a blog over at java.net (http://weblogs.java.net/blog/mullan/), but for now I will be posting new entries right here at blogs.sun.com. I may still update my blog at java.net from time to time, or figure out a way to cross-post my entries.

A little about myself. I work on the Java Security Team and have spent almost 10 years working on the Java SE security technology. I was specification lead of JSR 55 and co-specification lead of JSR 105, both successful APIs that were integrated into Java SE. I'm also Sun's representative on the W3C XML Security Working Group and a committer on the Apache XML Security project. Lately, I have been investigating and working on security features related to JavaFX and web-deployed technologies.

 Stay tuned for my next entry about the new CertificateRevokedException class in JDK 7.