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. >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. >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 >> >> >>
