JEP 116: Extended Validation SSL Certificates

AuthorXuelei Fan
OwnerXue-Lei Fan
Created2011/01/22 20:00
Updated2014/07/10 20:54
TypeFeature
StatusCandidate
Componentsecurity-libs
ScopeSE
Discussionsecurity dash dev at openjdk dot java dot net
EffortM
DurationL
Priority4
Issue8046106

Summary

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

Non-Goals

  1. Display visual indicators for EV SSL 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 visual indicators for EV SSL certificates, but that is not a goal of this proposal.

  2. Define public APIs to import extended validation policies into the JRE.

  3. Support for EV code signing certificates.

Success Metrics

Applications are able to get the extended validation status of EV SSL certificates when used in SSL/TLS connections.

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 on the details in the certificate.

If user interfaces do not clearly differentiate between low-validation certificates and those that have undergone more rigorous vetting, any successful SSL connection may be interpreted as having the same appearance. Users are not likely to be aware of whether the website owner has been rigorously validated or not. Therefore, fraudsters (including phishing websites) can use low-validation certificates 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.

Currently, the major browsers in use worldwide are high-security and EV-enabled including Microsoft Internet Explorer 7.0+, Firefox 3+, Opera 9.5+, Safari 3.2+ and Google Chrome.

Many well known CAs issue EV SSL certificates, including but not limited to Verisign, Entrust, GeoTrust, and Godaddy.

Description

  1. Define interfaces to identify EV SSL certificate-based SSL connections.

  2. Define interfaces to disable extended validation for EV SSL certificates if necessary.

  3. Enhance the SunJSSE provider implementation to validate EV certificates according to the CABForum standard, "Guidelines for the Issuance and Management of Extended Validation Certificates", version 1.4.6:

    https://cabforum.org/wp-content/uploads/EV-SSL-Certificate-Guidelines-Version-1.4.6.pdf

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 introduce new interoperability issues in unexpected ways.

Risks and Assumptions

One of the validation requirements for EV certificates is that the revocation status be checked using OCSP. Currently, revocation checking of SSL certificates is only supported on the client side, and is known to have performance issues. In order for the performance of EV certificates to be acceptable, OCSP stapling is probably required. OCSP Stapling is currently being proposed as another JEP (number TBD).

Impact