Storing Trust Policy, round two

[Stef Walter]

On 25.06.2013 21:37, Miloslav Trmač wrote:
> ----- 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"...

Indeed. We should define behavior here.

In the p11-kit trust module implementation: When a key is on both in the
set of anchors and in the black list, then the blacklist wins.

I think this behavior is appropriate, and easy to understand and
implement. Does it make sense to you? I've added a paragraph about it
here (last paragraph in section 3.5):

http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.html#model-layering

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

I'm working on the PKCS#11 remoting stuff as well.

That said, PKCS#11 has a lot of baggage and awkward implementation
issues. When one is already using it (such as within a crypto library)
it makes sense to also use it for trust.

However as we get further into storing key pinning, I think that there
will be non-crypto library callers of the trust stuff for whom PKCS#11
will be an obstacle.

I haven't jumped into defining these other APIs until we have specific
use cases, and perhaps only some of them are necessary.

One thing that a DBus API would give us is the ability to fit into the
PolicyKit model of privilege escalation. For example for the use case of
"install a system wide anchor".

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

Thanks. Fixed.

Stef