Transitioning the default keystore format to PKCS#12

[Michael StJohns]

At 02:20 PM 11/6/2012, Vincent Ryan wrote:

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

But they don't become "trusted".  My experience was that you had to explictly open up the tab and even then about half the time the cert wouldn't show up in the correct tab.  In some cases you could go in and adjust the trust state, but that didn't happen automatically.



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

Actually, an intermediate certificate MAY be a trust anchor, as long as it is also a CA certificate.  The one that is weird is the end entity certificate that you explicitly trust (e.g. I send you my email certificate and you don't have a trust anchor or valid chain for it, but you still want to send me email), but I'm not sure that why that would be in a P12 file.  Or if it is, why I would want to import it through the credential import process.

What I think you want for the TrustedCertificate entry is a trust anchor for the credentials other where in your P12 file.  On import, if the client certificate and key doesn't chain with existing anchors, you should go looking for TrustedCertificates in the P12 file to try and complete the chain.  At least that's what I think the KeyStore reason for having a TrustedCertificate should be.






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

Nope, TrustedCertificateEntry extends TrustAnchorEntry.  A trust anchor is either a public key and name or a certificate (which contains a public key and name). A certificate is just one particular way of representing a trust anchor.   Look at the TrustAnchor class API.  TrustedCertificateEntry would end up inheriting some methods from TrustAnchorEntry which would have methods similar to those in TrustAnchor to directly get the trust anchor name (certificate subject name) and public key.  

Mike