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

[Ryan Sleevi]

On Fri, Feb 15, 2013 at 8:47 AM, Miloslav Trmac <mitr at redhat.com> wrote:
> 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.

Revocation, for one. You may have accepted the error at a time when
revocation could not be obtained (or was not published), such as due
to the attacker sitting near the client network. If you're later
further from the attacker (eg: still communicating with the public
key, but you can now obtain revocation), it sure does seem like a
'more' serious error should not be able to override a 'soft' error
like a missing intermediate or name mismatch.

Every major browser implements this logic in how they manage
overrides, so I think it's at least worth considering how this would
work.

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

I trust $INSERT_NATIONAL_ID_CA to provide valid client certificates
for use with performing my tax return, but I do not trust the
intelligence services of $INSERT_NATIONAL_ID_CA to be able to MITM all
of my data.

I trust $QUESTIONABLE_CA to issue SSL server certificates, since
there's things like defined audit regimes and browser programs, but I
may not trust $QUESTIONABLE_CA to be able to perform code-signing that
may allow arbitrary executables on my device.

Do I need to trust my WiFi/EAP server cert the same as an arbitrary
SSL/VPN root? Maybe I don't trust the Wifi provider at all - which is
why I'm using SSL || VPN, to get 'honest' results over a potentially
dishonest connection.

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

Roots are rarely pairwise distinct in this space. Even Mozilla's
program recognizes three policies relevant to their applications: SSL,
E-Mail, and Code Signing. The same root, potentially the same (or
different) intermediates, with the trust bits NOT expressed via
certificate metadata but through the propagation/hierarchy of trust
bits.

The NSS trust bits are currently just that - bits - whereas a more
expressive policy is highly desired.

Even for the Wifi/EAP case, I trust this given cert for a given
BSSID/set of BSSIDs, but I don't necessarily trust them for all such
IDs. Especially when using authentication methods other than EAP-TLS
client certs (such as PEAP & friends), the use of EAP-TLS should not
be an 'everyone' or 'no one' situation.