JEP 166: Overhaul JKS-JCEKS-PKCS12 Keystores
|Discussion||security dash dev at openjdk dot java dot net|
|Endorsed by||Mark Reinhold|
|Relates to||6209038: merge JCEKS and JKS|
|8005408: KeyStore API enhancements|
Facilitate migrating data from JKS and JCEKS keystores by adding equivalent support to the PKCS#12 keystore. Enhance the KeyStore API to support new features such as entry metadata and logical views spanning several keystores. Enable the strong crypto algorithms introduced in JEP-121 to be used to protect keystore entries.
Simplify the task of interacting with Java SE keystores for cryptographic applications, and ease their development and deployment.
The current default keystore format is Java-specific and is not supported outside of Java SE. Applications are burdened with convering to and from our format. Facilitating easy migration to an open, widely-supported format would enhance interoperability with Java SE.
Java SE enforces security using cryptographic information stored in keystores. A variety of keystore implementations are currently supported. The default keystore format is called Java Key Store (JKS). JKS is a Java-specific format that is robust and has served the platform well since its inception. However, it suffers from some limitations and should be updated.
PKCS#12 is a more suitable format to use as the default Java SE keystore. It is an open specification which is widely supported by operating systems, PKI tools, and web browsers. Although it is a keystore format that is already supported in Java SE, several enhancements are required to enable trusted certificates and secret keys to be stored.
In addition, there is a long-standing requirement to support logical keystores that span several physical keystores. A logical keystore eliminaties the requirement to manage groups of keystores directly.
Ensure that the Mozilla OpenSSL Crypto Toolkit and popular web browsers can interact with our PKCS#12 format.