Storing Trust Policy, round two

[Stef Walter]

On 13.06.2013 19:22, Ryan Sleevi wrote:
> Thoughts/Suggestions:

Thanks for the review.

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

Yes an interesting problem. We should indeed have a solution for this. I
wonder if we can support both the form that's in the certificate (to
remain compatible with PKCS#11) and the normalized form.

Actually, do you happen to know how NSS deals with the difference
between CKA_SUBJECT and the normalized form of the DN.

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

Thanks! Fixed.

> 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

Indeed. There is a tradeoff. After much discussion on and off the
mailing list, the latter was the option that seemed to make the most sense:

At the core, the stapled extensions are a form of describing how the
system trusts the holder of key.

This is especially true when you consider that anchors are keys and
aren't necessarily keys (although they often take the form of certificates).

It's true that stapled extensions can also be used as a work around ot
override awkward contradictions or brokenness in a certificate or a
chain (aka: a hack). But this appears to be a secondary use case, and
the main one is describing trust policy.

Associating with a certificate certainly seemed simpler, and that's what
I had in the original revision, but did not model things correctly.

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

Interesting.

Cheers,

Stef