On Tue, May 2, 2017 at 11:11 AM, Rob Stradling <[email protected]> wrote:
> Ryan, please could you expand on precisely how and why it's technically > 'incorrect' to do, for example, the following... > > Root (Certificate Policies: none, so effectively anyPolicy) > Intermediate (Certificate Policies: just the BR DV OID) > Leaf (Certificate Policies: the BR DV OID and 2.23.140.x.y.z) > > ...or even... > > Root (Certificate Policies: none, so effectively anyPolicy) > Intermediate (Certificate Policies: a CA-specific EV OID) > Leaf (Certificate Policies: the same EV OID and 2.23.140.x.y.z) > > ? > > In other words, under what RFC5280-conforming circumstances would the fact > that 2.23.140.x.y.z doesn't appear in the Intermediate certificate actually > make any difference to the outcome? > > My reading of 5280 section 6 this morning (fueled by insufficient coffee, > I have to admit) was that: each of the policy OIDs in a cert are processed > independently; it's sufficient to match _just one_ OID in the Leaf and > Intermediate (in my examples above, that's the BR DV OID or the CA-specific > EV OID); therefore, the non-matching of 2.23.140.x.y.z would never actually > matter (as long as the BR DV OID, or the CA-specific EV OID, or anyPolicy, > are in the set of permitted policies). Perhaps I explained it poorly, because that's what I was trying to describe :) That is, you would not, as part of the inputs to RFC 5280, validate that Leaf was ever valid for 2.23.140.x.y.z (the user-initial-policy-set from https://tools.ietf.org/html/rfc5280#section-6.1.1 ). But the absence of it from the Intermediate would not cause RFC 5280 validation to fail, assuming the anyPolicy was given in the user-initial-policy-set - it just won't have 2.23.140.x.y.z in the resultant valid_policy_tree ( https://tools.ietf.org/html/rfc5280#section-6.1.6 )
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
