[cabfpub] Ballot 190

[Ryan Sleevi]

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