Storing Trust Policy, round two

Miloslav Trmač mitr at
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 mailing list