On 11/03/2016 02:23, Viktor Dukhovni wrote: > 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. You keep dodging the question: Does 1.0.2g trust or not trust intermediary certs found in the "CA" store? > > * 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. 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. > > * 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. 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. > > 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. 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. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160311/ddf49782/attachment.html>
