[cabfpub] Ballot 190

[Ryan Sleevi]

On Tue, May 2, 2017 at 11:44 AM, Rob Stradling <rob.stradling at comodo.com>
wrote:
>
> And if, as today, the Leaf cert doesn't contain 2.23.140.x.y.z, then the
> same is true: the leaf would never validate with the 2.23.140.x.y.z OID in
> the user-initial-policy-set.  Right?  If so, I'm not really sure why you
> think this approach would be "crude", tbh.


Because it's asserting a policy OID that's not valid within the policy
tree. Obviously, not asserting a policy OID that's not valid in the policy
tree is no big deal, as there's an infinite set of those that we don't
assert ;)

Again, I want to stress that it should technically work. But it also comes
with the side-effect that say, if a CP/CPS says "We only assert policy OIDs
that are valid in the policy tree" (and I have seen some CP/CPSes or
regulations to that effect, IIRC), then it means asserting the anyPolicy in
the intermediate, which may or may not be desirable.

It's assuming that CAs' software even lets them assert such policy OIDs. I
can totally see an issuance pipeline that refuses to allow issuance of a
leaf policy if the intermediate doesn't assert a compatible policy (via
policyMappings - which I have zero interest to support and it can die in a
fire, or via anyPolicy, or an explicit policy). So it's not necessarily
even a 'better' solution, from a "How deployable is this".  The purpose of
policy OIDs is to constrain through the issuance tree the validity, and
this is 'hijacking' that because it's expressing something about the leaf
that is explicitly _not_ constrained by the issuing intermediate.

The extension avoids that to some extent (because it's "just" an
intermediate extension), but comes w/o any ability to apply constraints.
It's a different trade-off, but one I think at least captures the 'current'
thinking. I was trying to avoid the over-engineering discussion (that's
possible with either solution) that could come about if, say, we wanted to
distinguish "This intermediate from this CA only uses methods 4, 7, and 10"
- (for which policy OIDs is absolutely the correct thing, but which clients
would need to supply it in the user-initial-policy-set), and instead focus
on "facts about the leaf" - for which an extension is entirely sufficient
and avoids the extra engineering (which I've now introduced and I'm sure at
least some will latch onto as a means of derailing conversion :P)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170502/574c2e48/attachment-0003.html>