Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 55: Certification Path API

Stage Access Start Finish
Final Release Download page 09 May, 2002  
Final Approval Ballot View results 04 Dec, 2001 17 Dec, 2001
Proposed Final Draft Download page 03 Oct, 2001  
Public Review Download page 08 Nov, 2000 08 Dec, 2000
Community Draft Ballot View results 03 Oct, 2000 09 Oct, 2000
Community Review Login page 09 Sep, 2000 09 Oct, 2000
Expert Group Formation   01 Mar, 2000 13 Mar, 2000
CAFE   12 Feb, 2000 29 Feb, 2000
JSR Approval   06 Feb, 2000 11 Feb, 2000
Status: Final
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0

The Certification Path API provides a set of provider-based APIs for creating, building, and verifying certification paths (also known as "certificate chains").

Please direct comments on this JSR to the Spec Lead(s)

Specification Leads
  Sean Mullan Sun Microsystems, Inc.
Expert Group
  Sun Microsystems, Inc.    

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Participant: Sun Microsystems, Inc.

Name of Contact Person: Sean Mullan

E-Mail Address:

Telephone Number: +353 - 1 - 8199176

Fax Number: +353 - 1 - 8199262

List of other Participants who endorse this JSR:


Section 2: Request

2.1 Please describe the proposed Specification:

An API for handling certification paths (also known as "certificate chains"). A certification path is an ordered list of certificates. If a certification path meets certain validation rules, it may be used to securely establish the mapping of a public key to a name.

The Certification Path API will include Provider-based APIs for creating, building, and verifying certification paths. A reference implementation will also be developed.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

desktop and server

2.3 What need of the Java community will be addressed by the proposed specification?

Many programs that use certificates must support certification paths as well. For instance, a signed email message usually includes a set of certificates. The recipient's email reader should use these certificates to build a certificat ion path from its trust anchors to the party that signed the email. Using this path, the signer's public key can be established and the signature on the email can be checked.

The JSSE and JDK (when verifying signed applets) each need to verify certification paths, but the code to do so is limited and not publicly accessible to other applications.

2.4 Why isn't this need met by existing specifications?

There are currently no APIs in the Java platform for working with certification paths, so each developer must write their own code to handle this.

2.5 Please give a short description of the underlying technology or technologies:

Certification path verification requires checking several requirements: that each certificate in the path is signed by the public key identified in the previous certificate, that name constraints are satisfied, etc.

The PKIX working group of the Internet Engineering Task Force ( has published several documents that describe certification path verification in more detail. See RFC 2459, for instance.

Techniques for certification path building are not as thoroughly documented, but they are also described in some PKIX documents.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

The Certification Path API consists of features that extend the functionality of the APIs defined in the package. Therefore, we believe that the APIs should be defined in the core JDK rather than as a standard extension (javax.*) as the functionality is useful and often required by Java applications which need to manage and verify certificates. As mentioned, the JSSE and JDK (when verifying signed applets) each need to verify certification paths, but the code to do so is limited and not publicly accessible to other applications.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?


2.8 Are there any security issues that cannot be addressed by the current security model?


2.9 Are there any internationalization or localization issues?


2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?


Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

Sun Microsystems has prepared an initial draft API for certification path building and verification. This draft will be made available as part of the JCP process.

3.2 Explanation of how these items might be used as a starting point for the work.

Sun Microsystems is in the process of implementing a reference implementation of the draft APIs based on the IETF PKIX standards. We'll contribute the APIs and reference implementation, as well as our expertise.