Transitioning the default keystore format to PKCS#12

[Vincent Ryan]

On 2 Nov 2012, at 04:14, Michael StJohns wrote:

> At 02:26 PM 11/1/2012, Vincent Ryan wrote:
> 
>> On 1 Nov 2012, at 17:50, Michael StJohns wrote:
>> 
>>> At 12:55 PM 10/31/2012, Vincent Ryan wrote:
>>> 
>>>> Before considering migrating the platform default keystore format to PKCS12 its keystore implementation
>>>> must at least match the functionality of JKS.
>>>> 
>>>> I have developed a prototype of a multi-format keystore that understands both JKS and PKCS12
>>>> formats - it checks for the JKS magic number to determine the format. By supporting both formats,
>>>> existing applications that access keystores using the platform default keystore format, continue to
>>>> function as expected.
>>> 
>>> 
>>> I think you may need to define a new keystore type for this provider instead of just reusing "pkcs12".   Either that or come up with a way to determine the keystore type from the keystore BEFORE creating an instance of the provider.  For example, you open up an old keystore of JKS type, you update it and you write it back. Do you write it back as a pkcs12 or jks?  Either choice you make is somewhat of a surprise...
>> 
>> If a keystore is loaded in JKS format then it is stored in JKS format too. And similarly for PKCS12 keystores.
>> New keystores in JDK8 would be created in PKCS12 format and new keystores in prior releases would be
>> created in JKS format.
>> 
>> Are you saying that it would be confusing for developers if the SunJSSE provider is capable of processing
>> a keystore in JKS format (previously the responsibility of the Sun provider)?
> 
> I normally use the suffix of the file to figure out which keystore type to instantiate.  So if the tag on the file is .keystore or .jks, normally I'm going to try and instantiate a "JKS" rather than depend on a default.  About the only time I use the default is if I'm just playing around.

That will continue to function correctly. If you instantiate a JKS keystore it can parse both JKS and PKCS12
formats. This is necessary for the special keystore named '.keystore' because it might be in either format.


> 
> Maybe the right thing is to modify SunJSSE.java to point "JKS" at "sun.security.pkcs12.PKCS12MultiKeyStore"?  
> 

That's possible. But since the Sun provider normally appears earlier in the list of providers that JKS setting
would be superfluous.



> But then you have the problem if you need to create a JKS for backwards compatibility....
> 
> I don't think there's a problem with changing the default to PKCS12 in the java.security file, but I think there will be problems with figuring out which keystore provider to use.
> 
> 
> 
> 
>>> 
>>> The other thing going on here is that pkcs12 is used almost entirely for one private key and one cert (with the possible addition of certs in the cert chain of trust).   While what you're doing is acceptable to the PKCS12 standard, I'm not sure it won't be confusing for other programs (simple check is to put multiple certs and keys in a file, and then try and import them using the microsoft cert tool).
>>> 
>>> 
>> 
>> I haven't tried using the Microsoft cert tool yet but OpenSSL seems happy enough.
> 
> Try Firefox as well.  Or feel free to send me a sample and I'll check it out for you.
> 
> 

Firefox will import the attached PKCS12 keystore containing just a single trusted cert
(pw: test123)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-cert.p12
Type: application/x-pkcs12
Size: 2446 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20121102/ed476f50/test-cert.p12>
-------------- next part --------------




> 
> 
>>> 
>>> 
>>> 
>>> 
>>>> In addition, storing trusted certs in PKCS12 is now supported. I've selected the X.509
>>>> extendedKeyUsage attribute to explicitly denote that a certificate is trusted - its default value is
>>>> trusted-for-any-purpose. This well-known attribute is stored with the certificate in a PKCS12
>>>> certBag.
>>> 
>>> 
>>> Before doing this, I'd suggest asking the IETF - probably the pkix working group - for comments.  I think they'll probably ask that you use something like id-kp-rootOfTrust (a OID to be defined), rather than the generic "AnyUsage".  Alternately, an Attribute with an oid of rootOfTrust with a null body may be a better choice.   Whichever you decide, it would be more than useful to document the usage and get the OID assignment.
>>> 
>> 
>> The appeal of re-purposing the extendedKeyUsage attribute is that it is already well known as a certificate extension. And in addition, it can be used by keystore owners to limit a cert's trust level to quite specific purposes.
> 
> This is one of those things where you have to read the fine print.  AnyKeyUsage means exactly that.  It means the key pair associated with this certificate can be used to sign pretty much anything and still be within policy. It says nothing about the trust status of the associated certificate or the public key within the certificate.  
> 

The goal is to annotate certs that the keystore owner has explicitly declared as trusted.

Any attribute could be used for this role but it seems more useful to choose a pre-existing one.
And the added benefit of choosing the extendedKeyUsage attribute is that the level of trust can be
constrained or unlimited, depending on the attribute's value.

I think the extendedKeyUsage attribute and its anyExtendedKeyUsage attribute value is ideal
for this role.



> What you want is an attribute that says "this certificate is a representation of a root of trust" and that attribute type doesn't exist AFAIK.
> 
> I sent a note off to the PKIX mailing list to see if anyone has already defined such a beast.  I should have an answer shortly.  If there isn't one, you can either assign one from Sun/Oracle/Java's arc (and write a 1 pager somewhere that describes the format) or better - write an Informational ID that defines the format and submit it for publication.
> 
> Mike
> 
> 
> 
> 
>> Thanks.
>> 
>> 
>> 
>>> Mike
>>> 
>>> 
>>> 
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~vinnie/jdk8-multi/webrev/
>>>> 
>>>> Please send me any comments.
>>>> Thanks.
>>> 
>>> 
> 
>