Advanced X509Certificate Methods

public abstract byte[] getTBSCertList Return the DER−encoded TBS certificate list −− that is, all the data that came with the CRL aside from the name of the algorithm used to sign the CRL and the digital signature itself. This data can be used to verify the signature directly. Parsing of the underlying data may throw a CRLException or an X509ExtensionException . public abstract byte[] getSignature Return the actual bytes of the signature. public abstract String getSigAlgName Return the name of the signature algorithm that was used to sign the CRL. public abstract String getSigAlgOID Return the OID string of the signature algorithm that was used to sign the CRL. public abstract byte[] getSigAlgParams Return the DER−encoded algorithms used in the signature generation. This generally returns null , as those parameters if any usually accompany the authoritys public key. There is one more method of the X509CRL class, which it inherits from its superclass, the CRL class java.security.cert.CRL : public abstract boolean isRevokedCertificate c Indicate whether or not the given certificate has been revoked by this CRL. When all is said and done, the point of the CRL class and the revoked certificate class is to provide you with the tools necessary to see if a particular certificate has been invalidated. Your application should perform this checking; you might choose to implement it as follows: package javasec.samples.ch09; import java.security.; import java.security.cert.; import java.io.; public class TestCertificate { Techniques to implement this method are shown in the next chapter. PublicKey getPublicKeyPrincipal p { return null; } Implementations of this method depend on the CA in use and are left to the reader. InputStream lookupCRLFilePrincipal p { return null; } public java.security.cert.Certificate importCertificatebyte data[] throws CertificateException { X509Certificate c = null; try { CertificateFactory cf = CertificateFactory.getInstanceX509; ByteArrayInputStream bais = new ByteArrayInputStreamdata; c = X509Certificate cf.generateCertificatebais; Principal p = c.getIssuerDN ; PublicKey pk = getPublicKeyp; c.verifypk; InputStream crlFile = lookupCRLFilep; cf = CertificateFactory.getInstanceX509CRL; X509CRL crl = X509CRL cf.generateCRLcrlFile; if crl.isRevokedc throw new CertificateExceptionCertificate revoked; } catch NoSuchAlgorithmException nsae { throw new CertificateExceptionCant verify certificate; } catch NoSuchProviderException nspe { throw new CertificateExceptionCant verify certificate; } catch SignatureException se { throw new CertificateExceptionCant verify certificate; } catch InvalidKeyException ike { throw new CertificateExceptionCant verify certificate; } catch CRLException ce { treat as no crl } return c; } } This method encapsulates importing a certificate and checking its validity. It is passed the DER−encoded data of the certificate to check this data must have been read from a file or other input stream, as we showed earlier. Then we consult the certificate to find out who issued it, obtain the public key of the issuer, and validate the certificate. Before we return, however, we obtain the latest CRL of the issuing authority and ensure that the certificate were checking has not been revoked; if it has been, we throw a CertificateException . Weve glossed over two details in this method: how we obtain the public key of the authority that issued the certificate and how we get the CRL associated with that authority. Implementing these methods is the crux of a keycertificate management system, and well show some ideas on how to implement the key lookup in Chapter 10. Obtaining the CRL is slightly more problematic since you must have access to a source for the CRL data. Once you have that data, however, its trivial to create the CRL via the generateCRL method.

9.5 Keys, Certificates, and Object Serialization

Before we conclude this chapter, a brief word on object serialization, keys, and certificates. Keys and certificates are often transmitted electronically, and a reasonable mechanism for transmitting them between Java programs is to send them as serialized objects. In theory −− and, most of the time, in practice −− this is a workable solution. If you modify some of the examples in this chapter to save and restore serialized keys or certificates, that will certainly work in a testing environment. A problem arises, however, when you send these serialized objects between virtual machines that have two different security providers. Lets take the case of a DSA public key. When you create such a key with the Sun security provider, you get an instance of the sun.security.provider.DSAPublicKey class. When you create such a key with a third−party security provider, you may get an instance of the com.xyz.XYZPublicKey class. Although both public keys are extensions of the PublicKey class, they cannot be interchanged by object serialization. Serializing a public key created with the Sun security provider Chapter 9. Keys and Certificates