JSRs: Java Specification Requests
JSR 55: Certification Path API
Section 1. Identification
Submitting Participant: Sun Microsystems, Inc.
Name of Contact Person: Sean Mullan
E-Mail Address: firstname.lastname@example.org
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 (http://www.ietf.org) 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.)java.security.certpath
The Certification Path API consists of features that extend the functionality of the APIs defined in the java.security.cert 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.