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)
test-cert.p12
Description: application/pkcs12
> > >>> >>> >>> >>> >>>> 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. >>> >>> > >
