[cabfpub] EV Gudelines section 9.2.5 & X.520

[Ryan Sleevi]

On Wed, Jul 13, 2016 at 10:26 AM, Rich Smith <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: <http://lists.cabforum.org/pipermail/public/attachments/20160713/518bf209/attachment-0003.html>