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.
