Storing Trust Policy, round two

[Miloslav Trmač]

----- 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.
> 
> http://p11-glue.freedesktop.org/doc/storing-trust-policy/

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?

Nitpicking:
Section 2.2, "signed by the key holder of the certificate" - is that "issuer"?
     Mirek