On 6 Nov 2012, at 14:21, Michael StJohns wrote: > 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.
Firefox can already import a PKCS12 file containing non-self-signed certs. They are displayed in the Others and Authorities tabs (as appropriate). > > 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. > But what about certs that are not trust anchors, such as intermediate CA certs. The trustAnchorBag would not be suitable for them > > > > >>>> 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. Currently we don't distinguish between intermediate certs and trust anchors: they're both stored in TrustedCertificateEntry. Do you mean make TrustAnchorEntry extend TrustedCertificateEntry? > > 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. Your comments are valuable. Thanks. > > 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 >>>>> >>>>> >>> > >
