Re: [lamps] struggling with CSRAttrs

[Russ Housley <[e-mail]>]

Michael:

I do not see the problem with IANA registries.  All of the other name registrations are here:

https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.8

They all begin with 1.3.6.1.5.5.7.8, which is id-on in the ASN.1 module.

Russ


> On Sep 30, 2022, at 5:22 PM, Michael Richardson <[e-mail]> wrote:
> 
> Signed PGP part
> 
> Corey Bonnell <[e-mail]> wrote:
>> Hi David,
> 
>>> (BTW, there is an erroneous self-reference to Section 6.2.2 within
>>> itself.)  In this section I miss a definition which OID(s) to use for
>>> acp-node-name etc.
> 
>> The errant section number reference should be 6.2.2.1 [1] (one of us
>> should file an errata on this), which defines “id-on-AcpNodeName” as:
> 
>> id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
>> …
> 
>> id-on-AcpNodeName OBJECT IDENTIFIER ::= { id-on 10 }
> 
> Yes.
> RFC8994's IANA section says:
> https://datatracker.ietf.org/doc/html/rfc8994#section-12
> 
>   For the otherName / AcpNodeName, IANA has assigned value 10 for id-
>   on-AcpNodeName in the "SMI Security for PKIX Other Name Forms"
>   (1.3.6.1.5.5.7.8) registry.
> 
> I found this text to be really difficult to parse.
> It's all there... leaf 10 in branch... but the actual OID does not show up in
> the text.
> I also wish that each allocation was always in a referenceable subsection.
> 
> Russ, do you think we could change how IANA documents assigned OIDs?
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> 
>