[cabfpub] Ballot 190

[Rob Stradling]

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

On 02/05/17 15:52, Ryan Sleevi wrote:
> Define valid?
>
> Yes, it's totally fine to use the OID as a policy signifier in a way
> that will not (negatively) impact validation, unless you attempt to
> positively assert "Valid for this OID"
>
> What I mean is that the leaf can use a number of OIDs to express the
> policies upon which it was issued/validated. If the intermediate lacks
> those OIDs, then you will not be able to validate (using RFC 5280) rules
> for that specific policy OID (e.g. if you say "Tell me if this cert is
> valid for this policy OID"), BUT that doesn't negatively impact policy
> validation to have that OID (e.g. if you say "Tell me if this cert is
> valid")
>
> The subtlety here is whether or not it's conforming with the purpose of
> policy OIDs, and whether or not we should overload that. There's an
> argument that "Ah yes, we all know how to add policy OIDs" which makes
> it quite appealing, but on the other hand, it creates the 'intentional
> incorrectness' if the intermediate lacks these policy OIDs (as one would
> presume).
>
> I don't have _strong_ feelings about it, but was proposing a way that we
> could do it "right" (new extension). If there are reasons within the
> technical infrastructure that would make this difficult/impossible to do
> in a timely fashion, certainly, the policy OID offers a solution, even
> if 'technically' incorrect.
>
> On Tue, May 2, 2017 at 6:02 AM, Rob Stradling via Public
> <public at cabforum.org <mailto:public at cabforum.org>> wrote:
>
>     On 02/05/17 10:23, Gervase Markham via Public wrote:
>
>         On 02/05/17 10:18, Rob Stradling via Public wrote:
>
>             Or you could embed all of this into a single Certificate
>             Policy OID.
>
>
>         (off-list)
>
>         Would that not be problematic if, as a previous message in the
>         thread
>         noted, there wasn't an anyPolicy OID in the intermediate? Or am I
>         misunderstanding how this works?
>
>
>     Hi Gerv.  I was about to reply "Oh yeah, you're right", but I
>     thought I'd first take another look at RFC5280 Section 6
>     (Certificate Path Validation)...
>
>     I *think* each of the policy OIDs in a leaf cert are processed
>     independently.  That is, as long as at least 1 of the OID(s) matches
>     the expected set, it's valid.
>
>     But please seek a second opinion on that.  I'm far from confident
>     that I understand correctly.  :-)

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online