[cabfpub] EV Gudelines section 9.2.5 & X.520

[Moudrick M. Dadashov]

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 
> <mailto: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 <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?
>
>     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 list
>>     Public at cabforum.org <mailto:Public at cabforum.org>
>>     https://cabforum.org/mailman/listinfo/public
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160715/de1c841e/attachment-0003.html>