JEP 116: Extended Validation Certificates

AuthorXuelei Fan
OrganizationOracle
Created2011/1/22
Updated2012/12/4
TypeFeature
StateCandidate
Componentcore/sec
ScopeJDK
RFE6878826
Discussionsecurity dash dev at openjdk dot java dot net
Start2012/Q1
EffortM
DurationM
Endorsed-byBrian Goetz

Summary

Support the Extended Validation (EV) SSL Certificate standard to provide improved authentication of entities that request digital certificates for securing transactions on web sites.

Non-Goals

  1. Display EV certificates in the Java plugin or other Java clients. It is possible and desirable for existing GUIs such as the Java plugin to be enhanced to display EV certificates, but that is not a goal of this proposal.

  2. Define the criteria for importing an extended validation policy into the JRE.

Motivation

An important motivation for using digital certificates with SSL is to add trust to online transactions by requiring website operators to undergo vetting with a certificate authority (CA) in order to get an SSL certificate. However, commercial pressures have led some CAs to introduce “domain validation only” SSL certificates for which minimal verification is performed of the details in the certificate.

Most browser’s user interfaces do not clearly differentiate between low-validation certificates and those that have undergone more rigorous vetting. Since any successful SSL connection causes the padlock icon to appear, users are not likely to be aware of whether the website owner has been validated or not. As a result, fraudsters (including phishing websites) have started to use SSL to add perceived credibility to their websites.

By establishing stricter issuing criteria and requiring consistent application of those criteria by all participating CAs, EV SSL certificates are intended to restore confidence among users that a website operator is a legally established business or organization with a verifiable identity.

As of March of 2009, 70% of browsers in use worldwide were high-security and EV-enabled including Microsoft Internet Explorer 7 and 8, Firefox 3, Opera 9.5, Safari 3.2, Google Chrome and Flock 2.0.

A lot of well known CAs issues EV certificates, including but not limited to Verisign, Entrust, GeoTrust, RSA Security and Godaddy.

Description

  1. Define interfaces to import extended validation policies into the Java Runtime Environment.

  2. Define interfaces to identify an EV certificate or identify the trust level of a given certification path.

  3. Define an interface to reject non-EV or insufficiently trusted certificates during certification-path building and validation and also during SSL/TLS handshaking.

We may also want to define the trustworthy level of a certain certification path. EV certificates is only one of multiple trustworthy levels. As would make the design flexible to support more trustworthy certificate policy. For example, the baseline requirements for the issuance and management of publicly-trusted certificates, issued by the CA/Browser Forum.

Testing

  1. Need to verify that the new interfaces behave as expected.
  2. Need to verify that the implementation doesn’t break backward compatibility in unexpected ways.
  3. Need to verify that the implementation doesn’t bring new interoperability issues in unexpected ways.

Impact