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

[Viktor Dukhovni]

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.