[cabfpub] EV Gudelines section 9.2.5 & X.520

[Ryan Sleevi]

Not really.

On Thu, Jul 14, 2016 at 3:24 PM, Moudrick M. Dadashov <md at ssc.lt> wrote:

> Thanks, Ryan, in that case Section 3.2.6.1.(Predefined Statements) of RFC
> 3739 would be more relevant.
>
> ETSI implementation here: ETSI EN 319 412-1, Electronic Signatures and
> Infrastructures (ESI); Certificate Profiles; Part 1: Overview and common
> data structures
>
> Thanks,
>
> M.D.
>
> On 7/13/2016 11:13 PM, Ryan Sleevi wrote:
>
> Moudrick,
>
> As the subject indicates, this is about naming OIDs, not policy OIDs -
> that is, the format and structure of name forms. So no, they don't
> represent policy OIDs, which do come from the CA/B Forum arc already.
>
> On Wed, Jul 13, 2016 at 11:37 AM, Moudrick M. Dadashov <md at ssc.lt> wrote:
>
>>
>> On 7/13/2016 8:33 PM, Ryan Sleevi wrote:
>>
>>
>>
>> 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?
>>
>>
>> Maybe not just "branding" :)
>>
>> Consider OIDs  specifically representing CA/B Forum policy provisions, I
>> mean similar to those in RFC 3739.
>>
>> Thanks,
>>
>> M.D.
>>
>>
>>
>>
>> _______________________________________________
>> Public mailing listPublic at cabforum.orghttps://cabforum.org/mailman/listinfo/public
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160714/c1642140/attachment-0003.html>