Storing Trust Policy, round two
mitr at redhat.com
Tue Jun 25 12:37:16 PDT 2013
----- Original Message -----
> Long in coming, but I've updated the document we were discussing earlier
> this year. Once again, the goal is to define a model and representation
> where we can share basic trust information between crypto libraries/apps.
In the PKCS#11 representation, a single object can be both CKA_TRUSTED and CKA_X_DISTRUSTED at the same time (or, in all representations, the same public key can be both an anchor and blacklisted, possibly through a certificate). Is it worth explicitly defining behavior for this case? Sure, it "shouldn't happen"...
Re: D-Bus API, wouldn't it be more useful to have a general PKCS#11 proxying/remoting API? Or do you expect a performance or maintainability advantage from having a trust-policy-specific API?
Section 2.2, "signed by the key holder of the certificate" - is that "issuer"?
More information about the p11-glue