problems with s_client recognizing revoked intermediate/subordinate ca

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 10, 2016 at 11:14:12PM -0500, Jeffrey Walton wrote:

> > However, in 1.0.x (more bug than feature) basic constraints, key
> > usage constraints and EKU constraints, which are applied to
> > intermediate certificates provided by the peer, are not applied
> > when the intermediate certificates happen to originate from the
> > trust store.
> 
> This seems like its a tricky area...

Note that in 1.1.0 and in the likely backport, the actual policy
mechanisms largely stayed the same.  The real change is removal of
inconsistency in how the mechanisms were applied.

Previously policy on intermediate certificates was inconsistently
applied, now the behaviour is predictable.  Whether found in the
trust store, or on the wire the processing is the same.

Please test the chain validation in 1.1.0, and if you find any
issues, please post here or to openssl-security at openssl.org as
appropriate.

The 1.1.0 code passes internal tests and the NIST PKITS tests.
Contributions of new tests that exercise more corner cases appreciated.
If a clear need for a separate "untrusted" store is identified that
can be added, with the key difficulty being a sane admin interface,
usable API and clear documentation.  The implementation is easy,
most of the code is there already, since untrusted certs are already
processed from the peer chain and any application provided "untrusted
stack", generalizing that stack to a store is easy enough.

-- 
	Viktor.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux