On Fri, Mar 11, 2016 at 05:54:57AM +0000, Viktor Dukhovni wrote:
> Absent augmentation as a "trusted certificate" for a given purpose,
> and with the application not enabling "partial chain" semantics,
> intermediate certs from the store just augment missing certificates
> from the wire, and should be verified in the same manner. The
> changes I want to backport from 1.1.0 ensure identical treatment
> of untrusted intermediates regardless of provenance.
I have an important question for the list. At present the pending
patches to backport from 1.1.0 to 1.0.2 do not change the default
chain construction strategy to X509_V_FLAG_TRUSTED_FIRST
commit ca9051b136284a96ea6c10ac4efd355cfc4716a0
Author: Viktor Dukhovni <openssl-users at dukhovni.org>
Date: Thu Feb 4 01:04:02 2016 -0500
Check chain extensions also for trusted certificates
This includes basic constraints, key usages, issuer EKUs and
auxiliary trust OIDs (given a trust suitably related to the
intended purpose).
Note, for this to work consistently, the X509_V_FLAG_TRUSTED_FIRST
flag must be set. This is the default in 1.1.0-dev, but is likely
too big a change for the 1.0.2 stable release.
(Backport from 1.1.0-dev)
What this means is that treatment of auxiliary trust "decorations"
for intermediate CAs is not predictable unless that flag is explicitly
set by the application. IIRC some people have been asking for this
flag to become the default (or at least requested its creation).
So I'd like to hear whether the above mentioned (pending) commit
is the right judgement call, or whether I should go ahead and update
X509_V_FLAG_TRUSTED_FIRST to be the default also in the next 1.0.2
release.
--
Viktor.
