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
