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

[Ryan Sleevi]

On Wed, Feb 13, 2013 at 10:26 PM, Stef Walter <stefw at redhat.com> wrote:
> 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?

As a browser vendor, we see a variety of errors caused by the
intermediates involved - from 'simple' errors like an intermediate
being expired to more complicated errors, like the aforementioned
policy violations (moreso when looking at the US FBCA and improperly
configured intermediates).

Overriding the leaf is done in the context of "As long as this (set)
of errors is consistent, and this (chain) is consistent, override the
error" - it's not strictly on leaf, nor does it bypass any arbitrary
error.

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

Respectfully, I'm not sure why you jumped straight to attacking the
business model as somehow being relevant to the security policy.

Microsoft (that is, pre-Win8 Microsoft) also approaches certificate
validation as a set of policies - and has since the days of IE3. This
recognizes that the PKIX path building algorithm is used by a variety
of applications for a variety of purposes.

It may be that you're *only* thinking of this in the context of
SSL/TLS as used by a user agent to communicate with a web server - and
that may have been a design space requirement I missed. But minimally,
the needs of validation differ between doing 'simple' RFC5280
validation, 'SSL/TLS' validation (which includes things like checking
EKUs and hostnames, among others), and things like EAP-TLS validation.
I imagine that as Red Hat/Fedora pursue the crypto consolidation,
other 'types' of verifications will emerge (notably, IPSec, which has
its own set of EKUs and policies).

I agree, ontologically the classification is hard, and if it means
that we simply constrain the problem to the set of problems facing
'browsers', that's reasonable - but we should at least be aware of the
different needs of applications and how they are (or are not) being
addressed.

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

For trust anchor management, yes. But you've introduced the notions of
pinning leafs as part of a TOFU (eg: Mozilla's "remember exception"),
and I'm trying to highlight that the problem space is not the same as
the TAMP setup - unless you're explicitly marking the leaf as a TAMP,
which throws out the rest of the verification model entirely (because
you don't verify attributes on anchors).

Regardless of the idealism, I think you will find, even with NSS, that
this would require rewriting many applications, and from what I
understand of the proposal (which may be mistaken), is not something
that will likely prove to be 'easy' to retrofit onto libpkix (or the
'legacy' verification, which is still what Firefox uses). For trust
anchor inputs, yes, but if the notion is to add overrides for
intermediates, that's further messier (especially when layered with
multiple sources for attribute overrides).

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

I see. I think that's unfortunate, but it's helpful to know where you
see the priorities are. I suspect this is something we would not be
able to use for Chromium then.

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

I don't think this is true in practice, from having worked with
systems that have initially tried this approach, but perhaps I've
misunderstood your proposal. If you're proposing merging (user &
system) settings, and having them both apply, then you can end up with
distinctly different security properties than an either/or system.