problems with s_client recognizing revoked intermediate/subordinate ca

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

 



>> >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.
>> ...
>
> They are not trust-anchors, so absent an issuer higher up, they
> are not sufficient to establish a "chain of trust", unless the
> application enables "partial chain" support.
>
> 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... The IETF and CA/B have different
issuing and usage policies, and there's no way to determine under what
policy a certificate was issued. You can kind of find CA/B sometimes
if they have one of those Extended Validation certificates based on
the cornucopia of OIDs. But IETF is Persian Bazaar because they lack a
way to denote policy.

If its a certificate issued under the IETF, then key usage expands
with the EKU of an intermediate. Under the CA/B, the EKU of an
intermediate contracts or constrains key usage.

Jeff


[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