comparison with other stored security state mechanisms [was: Re: Sharing Trust Policy between Crypto Libraries]
stefw at redhat.com
Wed Feb 13 22:26:04 PST 2013
On 14.02.2013 00:46, Ryan Sleevi wrote:
> I would discourage the notion of 'stapled extension' being used to
> store user overrides. The reasons for failures to a cert can not
> always be expressed as issues with end-entity certificates - for
> example, it may be due to chaining policies associated with the
> constructed chain, in which case, you don't want to override the leaf,
> you want to override the intermediate - but only in the context of
> that particular server.
What's the real world use case for that?
> I think Apple's approach to this problem is better, so it's just worth
> thinking about:
> Each certificate in Keychain has an array of TrustSettings objects.
> Each TrustSettings is a dictionary of key/value pairs that
> (collectively) must match. Only one of the keys need be specified - if
> more than one key is supplied, then all criteria must match for the
> TrustSettings to apply.
> - Policy (eg: SSL, S/MIME, X.509, Wireless, etc)
> - Policy-specific data (eg: a hostname for SSL, an e-mail address for S/MIME)
> - Requesting application (in this case, a code-signing identity)
> - Allowed error (a specific error code that may be overridden)
> - Result (the effective result to treat a certificate that matches
> this policy)
> See the documentation at
> This acknowledges several important use cases: ....
Well, for what it's worth, this approach is necessitated by Apple's
walled garden approach. Take a look at the arbitrarily defined
'policies' which defy generalization:
But the main problem with using this approach essentially necessitates a
complete rewrite of all certificate validation logic, and is not easy to
retrofit on existing crypto libraries. Likely this would be done in the
contect of combining all the X.509 certificate logic into a single
implementation and having the libraries call into it.
That's a mammoth project, has been tried before, and far beyond my
planned level of time investment in this effort.
The biggest benefit of using stapled certificate extensions for modeling
trust policy is that it can be retrofitted and/or implemented really
easily onto current certificate verification algorithms. While at the
same time giving consistency and the new abilities.
In addition (with the tweaks brought up on this mailing list) it is
exactly the same anchor model documented in such RFC's such as RFC5914
> 1) "overrides" (pinned settings) may be contextual dependent on the
> usage/purpose of the certificate
> 2) "overrides" (pinned settings) may be contextual dependent upon the
> error (or SET of errors)
> 3) "overrides" (pinned settings) do not attempt to 'rewrite' the cert
Of course that the Apple concept does not cover key pinning, and in our
use cases would be limited to X.509. But again these need to be modeled
But again, I'm not super turned on by the idea of "rewriting everything"
for a baroque technology such as X.509. Personally I'd like to see us
make X.509 work reasonably consistently, with perhaps enabling a few new
commonly requested trust policy use cases, and then invest our time in
other upcoming TLS authentication stuff.
> 4) [Not examined in depth] It also reflects a hierarchy of trust
> settings - User -> System [Admin Defined] -> System [OS defined].
On this last point, that's something Robert Relyea brought up, and in
the stapled certificate extensions there's a decent approach we can take
with stacking the sources of trust policy, including off machine sources
such as tokens.
More information about the p11-glue