comparison with other stored security state mechanisms [was: Re: Sharing Trust Policy between Crypto Libraries]

[Stef Walter]

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
> https://developer.apple.com/library/mac/documentation/security/Reference/certifkeytrustservices/Reference/reference.html#//apple_ref/c/func/SecTrustSettingsCopyTrustSettings
>
> 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:

http://www.opensource.apple.com/source/Security/Security-55163.44/sec/Security/SecPolicyPriv.h

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

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.

Cheers,

Stef