Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Java security evolution and concepts, Part 5

J2SE 1.4 offers numerous improvements to Java security

By Raghavan N. Srinivas, JavaWorld.com, 12/21/01

Page 4 of 6

Likewise, if alice were to validate bob's key, the certificate path bob-CA4-CA2-Root CA would be required, assuming alice trusts the Root CA's public key.

Figure 4. Hierarchy of CAs

To make such certificate-chain validation possible in programs, signatures must be verified, certification revocation and validity must be checked, and so on. Further, a certificate chain from the most-trusted CA to the subject may have to be found by other means, such as with access to LDAP (Lightweight Directory Access Protocol).

Building and validating certification paths is routinely carried out in security protocols such as SSL/TLS, S/MIME, IPSec, and so on. We saw how the Java Plug-in validated a certificate (or a chain). The Java CertPath API proves useful in all such cases.

I briefly examined X.509 in earlier articles of this series. The X.509 certificate standard in part provides confidence for doing business online. The Public-Key Infrastructure X.509 (PKIX) working group develops Internet standards needed to support X.509 PKI.

The Java CertPath API is based on the provider architecture introduced in the Java Connector Architecture (JCA). The provider architecture allows user programs to use the same API, but different providers can be plugged in via a Service Provider Interface (SPI). The Sun provider supports the PKIX standard.

Java CertPath API classes and interfaces

Now that we've seen Java CertPath's function, let's examine its classes for building and validating certification paths. Each class below exists in the java.security.cert package:

• Core classes:
  • The abstract CertPath captures the functionality shared by all certification path objects. For example, its getCertificates() abstract method returns the certificates list in the path.
  • In J2SE 1.4 the CertificateFactory now supports certification path objects.
  • The interface CertPathParameters specifies parameters to the Certification Path algorithms. For example, the class PKIXParameters that implements the interface can set PKIX parameters such as time of validity, policy constraints, target certificate constraints, and user-defined checks, among others.
• Validation classes:
  • CertPathValidator validates a certification path.
  • The CertPathValidatorResult interface captures the results from the CertPathValidator certification path validation.
• Building classes:
  • The CertPathBuilder class, like CertPathValidator, builds certification paths.
  • CertPathBuilderResult captures the results of CertPathBuilder's path building.
• Storage classes:
  • CertStore provides the functionality of a certificate and certificate revocation list (CRL) repository, such as LDAP. The methods getCertifcates() and getCRLs() retrieve certificates and CRLs, respectively.
  • CertStoreParameters specifies all CertStore parameters. In conjunction with the CertStore.getInstance()method, the CertStoreParameters class obtains a CertStore with the appropriate properties.
  • The CertSelector interface serves as an argument to the respective methods, allowing them to specify a set of criteria for the respective selection.
  • The CRLSelector interface also serves as an argument to the respective methods.

Having briefly looked at the classes and some methods, in the next section we see how to use them.