[cabfpub] Ballot 190

[Jeremy Rowley]

I like the idea of using policy OIDs better than a new extension, but we
should probably use the extension considering the concern over older
software. Anyone strongly opposed to the extension?  

-----Original Message-----
From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Rob Stradling
via Public
Sent: Tuesday, May 2, 2017 10:19 AM
To: Ryan Sleevi <sleevi at google.com>
Cc: Rob Stradling <rob.stradling at comodo.com>; CA/Browser Forum Public
Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Ballot 190

On 02/05/17 16:52, Ryan Sleevi wrote:
>
>
> On Tue, May 2, 2017 at 11:44 AM, Rob Stradling 
> <rob.stradling at comodo.com <mailto: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.

Ah.  I hadn't seen any such CP/CPSes.

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

That's the purpose of policy OIDs in intermediate certs, certainly. 
However, I think it'd be reasonable to interpret this as a stand-alone
sentence:
   "In an end entity certificate, these policy information terms indicate
    the policy under which the certificate has been issued and the
    purposes for which the certificate may be used."
(This kinda reminds me of the "gap" in the spec re: the use of EKU OIDs in
intermediate certs, and the resulting arguments that have spanned the last
decade or two ;-) )

But it's a moot point really.  "How deployable is this?" is indeed the right
question to ask, and the side-effect you just mentioned would be
undesirable.

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

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

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170502/4ae51e58/attachment-0001.p7s>