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

[Miloslav Trmac]

Hello,
I'm really new to the certificate validation area, so I might be completely off-base.  With that caveat...

----- Original Message -----
> 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).

I can see that overriding an intermediary to patch a particular certificate attribute might fix validation of a large number of leaf certificates; is there anything that would make this impossible to do with the stapled extension mechanism?

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

Why would I need this as an user?  If I have overridden a specific leaf certificate (whether that was because I had a good reason or because I don't understand things and just want to dismiss an annoying dialog), I have also implicitly accepted the binding of a specific server identity and a specific public key.  What do I care that the chain has changed or that the reasons for why the chain is invalid have changed?  I have already determined that I trust the specific public key for the specific server identity, I don't need the chain.


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

The "policy" word was a little confusing to me.  Again, once I have accepted a specific public key for a specific name, why would applications have different "policies" on whether to accept that key or not?  That doesn't make any sense.

Perhaps we are actually talking about different sets of roots of trust:
- "Within the DNS name space, we use the ugly CA ecosystem, and have the $huge_number of roots
- For OpenVPN connections, this single CA is the only accepted root of trust
and the like.  From that point of view it makes perfect sense to have a separate corporate-specific root of trust for, say, iPhone provisioning profile signing.

The current proposal can't support separate roots of trust.  However, if that were added, can't the stapled certificate mechanism can still be used for the intermediates and leafs?  If the roots of trust are pair-wise distinct, the intermediates and leafs that can be validated from each root of trust should also be pair-wise distinct, shouldn't they?
    Mirek