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

[Jakob Bohm]

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>