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 <[email protected]
<mailto:[email protected]>> wrote:
On 7/13/2016 8:33 PM, Ryan Sleevi wrote:
On Wed, Jul 13, 2016 at 10:26 AM, Rich Smith
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
