[openssl-users] problems with s_client recognizing revoked intermediate/subordinate ca

[Viktor Dukhovni]

On Fri, Mar 11, 2016 at 02:44:59AM +0100, Jakob Bohm wrote:

> >Well, no, 1.0.2 uses the trust store not only for trust-anchors,
> >but also as a capricious source of intermediate certificates, whose
> >behaviour varies depending on whether the peer supplied same said
> >certificates on the wire or not.  I expect to improve the capricious
> >behaviour.
>
> You keep dodging the question: Does 1.0.2g trust or not
> trust intermediary certs found in the "CA" store?

They are not trust-anchors, so absent an issuer higher up, they
are not sufficient to establish a "chain of trust", unless the
application enables "partial chain" support.

However, in 1.0.x (more bug than feature) basic constraints, key
usage constraints and EKU constraints, which are applied to
intermediate certificates provided by the peer, are not applied
when the intermediate certificates happen to originate from the
trust store.

As for CRL checks, these apply to either just the leaf certificate
(flags & X509_V_FLAG_CRL_CHECK) or all certificates in the chain
(flags & X509_V_FLAG_CRL_CHECK_ALL).   Perhaps the OP's application
is only setting the first flag and not the second.

> >  * CRL checks, expiration checks, and EKU restrictions will apply
> >    to all chain elements below the trust anchor (principle of least
> >    surprise) regardless of origin (wire or trust store).  This
> >    avoids violating the principle of least surprise.

Sorry, I was wrong about CRL checks, these do not depend on CA
provenance.

> And just to beat a dead horse again: Why skip those
> checks for the trust anchor too?  A trust anchor can
> expire, be revoked or have insufficient EKUs just like
> any other cert.

When the trust-anchor is not self-signed, it is not possible to
check its revocation, because the issue is missing.  The expiration
dates and self-signatures of trust-anchors are not checked by
yedefault.  I've not checked whether a trust-anchor can revoke
itself via a CRL, I'm not proposing changing CRL processing, just
chain construction (trusted-first by default) an extension processing
(EKUs, basic constraints, ...).

> >Yes, there is not in either 1.1.0 or 1.0.x a separate store of
> >intermediate certificates, that is just a local cache of certificates
> >erroneously left out of the peer's chain.
>
> Point is that if 1.1.0 introduces code that can load a
> certificate from the trust store without trusting it,
> then that new code should not be reusing a store which
> other software treats as a store of trust anchors.

That code has existed well before 1.0.x, and continues to be present
in 1.0.x, the difference from 1.1.0 is that in 1.0.x, such certs
are subjected to less validation than they deserve.  The proposed
changes are to apply all the expected checks.

> >My instinct is that giving administrators a new intermediate-CAfile
> >and intermediate-CApath to manage (to keep mostly empty) would not
> >prove especially popular.  Placing undecorated intermediate certs
> >in the trust store is much simpler.
>
> An intermediate-CApath store would typically act as a
> growing cache of encountered intermediaries, needing a
> lot less security considerations than a trusted-CApath.
> 
> This is especially useful with protocols and protocol
> variants where the convention is to not send the full
> certificate chain at all, but rather to expect the
> opposing end to request (and cache) any missing
> intermediaries as necessary.

Fine for browsers, not so practical for OpenSSL which does not go
around downloading certificates on the fly.

Anyway, I think we're no longer making anything more clear, so
we should stop.

-- 
	Viktor.