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

[Gabor Toth]

>>>>> On Fri, 15 Feb 2013 11:47:02 -0500 (EST), Miloslav Trmac <mitr at redhat.com> said:

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

The problem is that stapled extensions are specific to a certificate, while
overriding error conditions is done on a per-peer basis. Trying to fix a
certificate by stapling to make it valid would be more complicated, and could
have unintended consequences if stapling is done in a way that makes it valid
for other cases as well, like another host name, usage, etc. It might not be
impossible to do this, but it is certainly more complicated and error-prone.

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

This is more fine-grained than that in my opinion: when a user overrides certain
attributes of a certificate, this is done in the context of the specific error
message and the current trust anchors in use. For instance, one would
override a certificate because it has expired, but seems otherwise trusted.
At a later point the CA that signed the certificate could be distrusted,
in which case it makes sense to present a (different) error message for the
certificate in question again, as the error conditions have changed.

The same applies to TOFU pinning: an otherwise trusted certificate could be
pinned automatically, but if it expires or trust is later revoked from a CA that
signed it, one might want to revise this decision, thus overriding the newly
occurred validation failures would be necessary.

Storing the exact error flags together with where it occurred in the chain,
would accomplish this.

-tg