On Tue, May 2, 2017 at 11:34 AM, Rob Stradling <[email protected]> wrote:
> On 02/05/17 16:15, Ryan Sleevi wrote: > <snip> > >> Perhaps I explained it poorly, because that's what I was trying to >> describe :) >> > > Great. Maybe I had had enough coffee. :-) > > 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 ) >> > > If anyPolicy is not in the user-initial-policy-set, but the BR DV OID (for > my first example) or the CA-specific EV OID (for my second example) is in > the user-initial-policy-set, that would also suffice, right? Correct. None of the implementations today by the member browsers (except for the possibility of 360, which I've not examined) provide BR DV OIDs in the user-initial-policy-set, but 'most' will, on encountering a leaf asserting a CA-specific EV OID, will attempt to supply that policy OID in the user-initial-policy-set. In both cases, the presence of an (unrelated) OID will work. My remarks about the 'incorrectness' of it were with respect to the fact that, as structured and implemented (and without the intermediate asserting anyPolicy, which arguably is a desirable property - that is, to not require/encourage intermediates to assert anyPolicy), the leaf would never validate with the 2.23.140.x.y.z OID in the user-initial-policy-set. It's 'effective', just 'crude', from an engineering perspective :)
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
