[cabfpub] Ballot 190

[Ryan Sleevi]

On Tue, May 2, 2017 at 11:34 AM, Rob Stradling <rob.stradling at comodo.com>
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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170502/33d3b465/attachment-0003.html>