Storing Trust Policy, round two

[Ryan Sleevi]

Thoughts/Suggestions:

In an ideal world, I would recommend that both Subject and Issuer are
stored in RFC 3280/5280 name-normalized form. That is, duplicate
whitespace eliminated, case normalized (since case matches are
insensitive), etc. The downside is this requires all libraries using
this to support name normalization - I don't know if that's an
acceptable requirement, but I would hope it is. [This would also match
both OS X and Windows with respect to trust anchor stores]

Section 3.3 reads "Anchors", but probably meant to read "Blacklist"

Adding Stapled Extensions via Public Key can be both Good and Bad.
Bad:
  1) A public key can be associated with multiple Distinguished Names,
and the extensions only apply when under a certain name
  2) Even with the same Subject+SPKI, a certificate may exist in
multiple forms (eg: cross-certified), where the policy is that "If
using X as a trust anchor, Policy Y applies, but if using X as part of
a transitive chain to Z, then policy Z applies"
Good:
  1) Even if another version of a cert exists, you can uniformly apply
restrictions to it

JSON representation - I wouldn't worry about this. The JSON form used
by Chromium, for example, is just an intermediary step for an
automated generator when source compiling. A C ABI (or simply the
PKCS#11 module spec) is more than sufficient.




On Thu, Jun 13, 2013 at 5:00 AM, Stef Walter <stefw at redhat.com> wrote:
> 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/
>
> Thanks for all the helpful comments and insight. Here are some notes on
> what's changed:
>
> Split up the document into an more abstract model, with representations
> documented separately. Currently only one representation (PKCS#11) has
> been fleshed out. Placeholders for several others exist. Looking forward
> to working together on others as the need arises.
>
> Clarified the scope of the document. Currently the scope is representing
> anchors and black lists. Although this is clearly targeted at validating
> certificate chains for TLS and SSL, the feedback everyone gave allows it
> to be more useful than just that. For example, the blacklist contains
> public keys, so it could be used for things like SSH as well.
>
> In the future we can tackle key pinning (and related certificate
> exceptions). Removed this from the document at present.
>
> Clarified that applications/implementations use additional trust
> information along with the shared information as input.
>
> Clarified that this is about local storage, not sharing information
> remotely. Removed the erroneous attempt at defining an ASN.1 format.
>
> Trust anchors are no longer only certificates, although that is one
> (very common) form that they take. The model allows for public keys to
> be trust anchors.
>
> Updated the NSS trust object documentation based on insight received
> from Bob Relyea.
>
> Added information about layering various stores (system trust vs. user
> defined trust).
>
>
> In all I hope this revision makes much more sense than the previous
> extremely rough document.
>
> Thanks again for your insight and comments.
>
> As before, the git repo for the document is here:
>
> http://cgit.freedesktop.org/p11-glue/p11-glue/
>
> FWIW, the p11-kit trust module implements parts of this model, and I'll
> work to bring it in line with what's in the document.
>
> Cheers,
>
> Stef
> _______________________________________________
> p11-glue mailing list
> p11-glue at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/p11-glue