On Fri, Mar 11, 2016 at 01:51:32AM +0100, Jakob Bohm wrote: > I am arguing that: > > - 1.0.x behavior should not be changed, as it would violate the > principle of least surprise for a "security update" to change > semantics. The odd 1.0.x behaviour leads to periodic email to openssl-security, in which it is typically suggested that the 1.0.x behaviour violates user expectations. Changing the 1.0.x behaviour addresses some corner-case behaviour, and would not be inappropriate for a future 1.0.2 release. Keep in mind that 1.0.2 (unlike 1.0.1) gets bug fixes not just security fixes. I have no plans to backport the changes to 1.0.1 (EOL this December, security fixes only). > - Therefore the 1.1.0 behavior should use the CA directory shared > with 1.0.x in a way consistent with how 1.0.x uses that directory > (as a repository for trust anchors only, as far as I understand > your non-replies), while 1.1.0 should store untrusted intermediary > certificates in a different directory where they don't affect > 1.0.x instances running on the same machine. 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. * The treatment of untrusted intermediates (not decorated with explicit auxiliary EKUs) will be same regardless of origin. * 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. * Partial chains (when enabled) will not extend beyond "intermediate" CAs that have been "decorated" with auxiliary EKUs. 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. Such a thing could be added to whatever release follows 1.1.0 if there is sufficient demand or someone donates an implementation that looks like a sufficiently compelling and well documented feature. 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. -- Viktor.
