[cabfpub] EV Gudelines section 9.2.5 & X.520

[Rich Smith]

Ryan,
My suggestion was based purely on the fact that any documented use of 
these OIDs is, to the best of my knowledge, only in CA/B Forum work 
product, so it seemed a good idea to me, now that we can, to transition 
them to actually being CA/B Forum OIDs.  I don't have strong feelings on 
the matter, but I do think it makes things cleaner over the long haul, 
especially should we decide to add other related OIDs into future work 
product, to have them managed in house.  But I do take your point as to 
it being a lot of technical changes, both on browser/relying party side 
and CA side for what, at least at this moment in time, has pretty much 
zero need or payback aside from the above mentioned possible future 
'benefits'.
-Rich

On 7/13/2016 12:33 PM, Ryan Sleevi wrote:
>
>
> On Wed, Jul 13, 2016 at 10:26 AM, Rich Smith <richard.smith at comodo.com 
> <mailto:richard.smith at comodo.com>> wrote:
>
>     I don't have any concrete objection to these OIDs being maintained
>     under Microsoft's hierarchy, however as memory serves they were
>     put there because at the time the CA/B Forum did not have an OID
>     hierarchy of our own under which to create them.  Personally I
>     think it would be a good idea to duplicate these OIDs in house at
>     this point, and over time deprecate the use of the ones under the
>     Microsoft structure.  I don't think this is a pressing issue, and
>     probably not even strictly necessary, but I do see it as a matter
>     of good 'house-keeping'.  If they're under CA/B Forum control we
>     don't need to ask someone else to define them, and we don't have
>     to accept their definition if it's one we don't necessarily agree
>     with.
>
>
> I'm not sure I understand these last points, practically speaking.
>
> Why is it a matter of good-housekeeping? The counter-argument is it 
> sounds like NIH-syndrome.
>
> Why do we need to ask someone to define them, considering they're 
> defined already? Why do we need to worry about accepting the 
> definition, considering it's already been accepted?
>
> I'm explicitly opposed to the change as argued because it means 
> needless churn and complexity in software. If this were a fresh start, 
> I would be understanding - but even then, I'd be opposed to putting it 
> under a CA/B Forum arc 'simply because', if an alternative presented 
> itself. For example, if a member/vendor in possession of a small OID 
> arc were willing to 'donate' OIDs for future purposes that were 
> smaller, in their encoded form, then the OID arc of the CA/B Forum 
> (presently, 2.23.140, so I mean, it's unlikely but possible), then 
> great - let's do that instead.
>
> I'm also not opposed to moving to a CA/B Forum set of OIDs if there 
> were other compelling reasons to. But so far, it seems to solely be 
> about 'branding' than any concrete technical need. Am I missing something?
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160713/ecc64512/attachment.html