Transitioning the default keystore format to PKCS#12

[Michael StJohns]

At 03:52 PM 11/5/2012, Vincent Ryan wrote:
>On 05/11/2012 18:28, Michael StJohns wrote:
>>At 09:17 AM 11/5/2012, Vincent Ryan wrote:
>>>Thanks for your suggestion Mike. I quite like that approach but I'm concerned that existing tools and
>>>browsers do not support this new type of PKCS12 safe bag.
>>
>>I went back and took a look at the PKCS12 standard.  The ASN1 defining the list of bag types ends with an elipsis "..." which indicates extensibility.
>>
>>I just took a look at the code for BouncyCastle - it just prints a "file has extra data" and continues.
>>
>>I'm digging into the Openssl code - it appears to do the right thing with the ASN1 parsing - still tracking back to the app code.
>>
>
>I know these tools can successfully parse arbitrary PKCS12 elements - I have already done some testing using the PKCS12 Secret Bag to store
>symmetric keys.
>
>My point is that the parsers will just ignore unrecognized elements.
>One of the goals of this feature is to migrate from JKS to a format
>that is more interoperable with commonly used PKI-aware components.


Yes but... :-)

A certificate unpaired with a private key will not be imported with existing tools.  (MS certmgr and firefox/thunderbird).  If its paired with a private key, it gets imported into the personal cert portion of the certificate store.  It's possible I'm missing an incantation to do this, but generally you import a trust anchor as a bare certificate - a .x509 or .crt or even a .der file.

If you want the trustedCert to be imported on the fly, these programs will need to be updated regardless of the mechanism chosen.  I'd rather you went down the trustAnchorBag approach as I think it matches more closely with the need.





>>>If we could overcome the issue with using extendedKeyUsage as a bag attribute then I think that the
>>>current proposal using cert bag would be a more interoperable solution.
>>
>>
>>I talked to the author of RFC5914 and proposed both your original approach and my suggestion.  If anything I think he was more opposed to using ExtendedKeyUsage in this approach than I am.
>>
>>If you want to do this, you need to find something that's typed as an ATTRIBUTE,  and that's got an unambiguous meaning of "this cert is considered to be a trust anchor".   I can't find an OID that means this and I've looked.
>>
>
>So that leaves defining a new attribute that denotes a cert's level
>of trust. I guess it could also be used to denote a lack of trust or a prohibition of trust.

Yup and that's a new internet draft and rfc and the process of getting an OID assigned - before you complete the coding.  Using the trustAnchorBag approach only really requires an ID after the fact and can be either informational or standards track and will mostly define what a program should do when it sees a trustAnchorBag in a P12 file. 

Looking at the existing classes and what's gone on since they were originally defined, would it make sense to create a KeyStore.TrustAnchorEntry and then make KeyStore.TrustedCertificateEntry a sub class of that?  That would pair well with the TrustAnchor class and would be closer to what the PKIX folks do.  It also matches a bit better with the PKCS11 trusted public key stuff.

Sorry to push back so hard - but I think this is one of the few places where you really need to get it right the first time as it will be impossible to fix later.

Mike









>>>On 4 Nov 2012, at 21:31, Michael StJohns wrote:
>>>
>>>>At 11:14 PM 11/1/2012, Michael StJohns wrote:
>>>>>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.
>>>>>
>>>>>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
>>>>
>>>>
>>>>I haven't heard back from the PKIX group, but take a look at RFC5914 - section 3 - Trust Anchor List.
>>>>
>>>>Instead of adding an attribute in a CertBag with a type of ExtendedKeyUsage:AnyKey, instead, use the type and values in this section to create a TrustAnchorBag - use TrustAnchorList as the format and id-ct-trustAnchorList as the OID for the bag type.
>>>>
>>>>Doing it this way allows you to avoid overloading the CertBag / PrivateKey pairing model, and should be an acceptable way of including trust anchors in a P12 file.
>>>>
>>>>
>>>>I'm going to try and grab the author(s) of 5914 and see what they think.
>>>>
>>>>Later, Mike
>>>>
>>>>
>>