JEP 116: Extended Validation SSL Certificates
|Discussion||security dash dev at openjdk dot java dot net|
|Relates to||6878826: Add support for Extended Validation certificates|
Support the Extended Validation (EV) SSL Certificate standard to provide improved authentication of entities that request digital certificates for securing transactions on websites.
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.
Define public APIs to import extended validation policies into the JRE.
Support for EV code signing certificates.
Applications are able to get the extended validation status of EV SSL certificates when used in SSL/TLS connections.
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.
Define interfaces to identify EV SSL certificate-based SSL connections.
Define interfaces to disable extended validation for EV SSL certificates if necessary.
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:
- Need to verify that the new interfaces behave as expected.
- Need to verify that the implementation doesn't break backward compatibility in unexpected ways.
- 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).
- JCP: no impact on JCP
- Other JDK components: no impact on other JDK components
- Compatibility: minimal
- Security: no impact on security
- Portability: limited impact on portability
- User Interface: Deploy may update the display style for EV SSL certificate
- Documentation: need to document the new interfaces
- Internationalization: minimal impact, likely to add new error messages
- Localization: minimal impact, likely to add new error messages
- Legal: no legal issue for software development
- Other: no known other impact