>> >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
