JEP 124 Review

Introduction

JEP 124 is a proposed Java Enhancement to enhance the Certificate Revocation Checking API. As stated in the JEP, it has 3 main goals:

Provide API support for best-effort checking. With best-effort checking, a certificate is not considered invalid if a connection cannot be made to the server holding the revocation information.
Provide API support to independently check the revocation status of a certificate rather than every certificate in the certificate chain.
Provide API support for revocation checking options that are currently specified as system properties. Add additional parameters specific to the type of revocation checking mechanism used, CRLs or OCSP.

Note: Since filing the JEP, the importance of goal #2 has been reevaluated. The original motivation is that it would allow an implementation to periodically check if a certificate (for example, a code-signing certificate used to sign some application that you had previously installed) was still ok (not revoked). However, a better solution that is more commonly used in practice is to time-stamp the application when it is signed. This allows an implementation to check that the certificate was not revoked at the time the application was signed. If the application was found to have a vulnerability after it had been signed, other mechanisms such as blacklisting can be used to block that application from being installed or executed. The JEP will be updated to remove this goal.

API

A specdiff of the current API is at specdiff/package-summary.html. Click on the name of the file in the table titled "Package Detail" to view the javadoc for each API change. The primary API changes (all in java.security.cert) are the following:

A new getRevocationChecker method has been added to CertPathValidator (and a corresponding engineGetRevocationChecker method to CertPathValidatorSpi) that returns a CertPathChecker.
Similarly, a new getRevocationChecker method has been added to CertPathBuilder (and a corresponding engineGetRevocationChecker method to CertPathBuilderSpi) that returns a CertPathChecker.
A new interface named CertPathChecker has been defined to be used for checking any type of certificate, and PKIXCertPathChecker now implements CertPathChecker.
A new class named PKIXRevocationChecker has been defined to accept revocation specific parameters for the PKIX algorithm. This class extends the PKIXCertPathChecker class. It also defines a static Enum class named Option specifying various revocation options that can be set.

Examples

Here is an example of using a PKIX CertPathValidator to validate a certificate chain and setting best-effort checking (SOFT_FAIL) so that if a network issue prevents the revocation information from being obtained it is not considered a failure.

    // KeyStore loading and CertPath creation not shown
    CertPathValidator cpv = CertPathValidator.getInstance("PKIX");
    PKIXRevocationChecker prc = (PKIXRevocationChecker)cpv.getRevocationChecker();
    prc.setOptions(EnumSet.of(Option.SOFT_FAIL));
    PKIXParameters params = new PKIXParameters(keystore);
    params.addCertPathChecker(prc);
    CertPathValidatorResult res = cpv.validate(certpath, params);

Here is an example of using a PKIX CertPathBuilder to build and validate a certificate chain and use a specific OCSP responder.

    // KeyStore loading and target constraints creation not shown
    CertPathBuilder cpb = CertPathBuilder.getInstance("PKIX");
    PKIXRevocationChecker prc = (PKIXRevocationChecker)cpb.getRevocationChecker();
    prc.setOCSPResponderURI(new URI("http://localhost"));
    PKIXBuilderParameters params = new PKIXBuilderParameters(keystore, constraints);
    params.addCertPathChecker(prc);
    CertPathBuilderResult res = cpb.build(params);