Using Digital Signatures and Certificates in Java, Page 2
Java Certification Path API
The classes for verifying and building certification chains are located in the Java Certification Path API. This specification defines the two key classes: java.security.cert.CertPathValidator, purposed for verification of certification chains, and java.security.cert.CertPathBuilder, purposed for building certification chains from a given set of trusted Root-certificates and a given set of certificates that can be used as intermediate members of the chain.
We will briefly describe the most important classes from the Java Certification Path API that we will use in our further work:
java.security.cert.CertPath—represents a certification chain (ordered sequence of certificates). A standard certification chain starts from some end-user certificate, followed by zero or more certificates of intermediate certification authorities (CA), and ends with a Root-certificate of some top-level CA. Each certificate in the chain, except the last one, is issued and signed by the next certificate after it. The CertPath class is purposed to keep such correctly formed certification chains, but also can keep sets of certificates that do not form a certification chain.
java.security.cert.TrustAnchor—represents an end point of trust used in the process of verification of certification chains. It consists of a public key, a name of trusted certification authority, and a set of constraints that restrict the set of paths that can be checked. The set of constraints is empty by default and usually is not used. We can think about the TrustAnchor objects like the trusted Root-certificates used during the verification of certification chains; in other words, the Root-certificates of these CA that we trust unconditionally.
java.security.cert.PKIXParameters—it is a auxiliary class that describes the parameters of the PKIX algorithm, used for verification of certification chains. These parameters include a list of end points of trust for the verification (set of TrustAnchor objects), the date for which the verification should be performed, option that indicates if CRL lists should be used, and some other settings for the algorithm.
java.security.cert.CertPathValidator—provides functionality for verification of certification chains. When we create an instance of this class, we specify the verification algorithm that should be used. In most cases, the PKIX algorithm (see RFC-3280) is used. When verifying certification chains, the PKIX algorithm starts from the first certificate in the chain (the end-user certificate), continues with the next certificates, and finishes with the last one. It is necessary this last certificate from the chain to be signed by some certificate that is in the list of the end points of trust used for the verification (the set of TrustAnchor objects).
By specification, the chain that is to be verified should not contain the end point of trust; it should not finish with the Root-certificate of some CA but with the next before it. Due to this strange problem when we read some certification chain from a protected keystore before starting to verify it, it is necessary first to remove the last certificate from the chain. Otherwise, it is possible for the verification to fail despite the fact that the chain is valid.
The method for the verification of the validate() certification chain requires as input parameters the chain for verification (with the last certificate removed beforehand) and the parameters for the verification algorithm. For the PKIX algorithm, these parameters should be an instance of the PKIXParameters class that contains the list of the trusted CA Root-certificates that should be used as end points of trust.
My next article will provide an analysis of the most essential problems connected with the digitally signing of documents in Web-based systems and suggests a particular solution for them. Motivated is the need for using a digitally signed Java applet that is integrated with the Web application and signs the files on the client's machine before uploading them to the server. The problems related to Java applets signing and interoperability between applets and Web browsers are examined. The mechanisms for verification of digital signatures, certificates, and certification chains and the possibilities for their particular application are also discussed and analyzed.
About the Author
Svetlin Nakov is part-time computer science lecturer in Sofia University,
Bulgaria. He has over 5 years of professional software engineering and
training experience and currently works as IT consultant in a leading
Bulgarian software company. His areas of expertise include Java and related
technologies, .NET Framework, network security, data structures and
algorithms, and programming code quality. More information on his research
background, skills and work experience is available from his home site