Subject: [Anima] ANIMA-WG: pls chime in: early allocation for otherName code points (draft-ietf-anima-autonomic-control-plane)

From: Toerless Eckert <[email-masked]>
Date: Thu, 2 Jul 2020 15:29:22 +0200

Dear WG (ACP author head/hat on)

ACP Revision -26 introduced a new otherName / AcpNodeName encoding for the ACP Domain Information
(now call AcpNodeName / acp-node-name). Michael Richardson (and potentially other) implementors
would like to update implementation to use this new encoding for interop testing,
which requires allocation of two IANA code points (technically i think only one is
required for the implementation, but the toolchain would require both if i understand it
correctly).

The early allocation process RFC7120 requires to vet the community for interest in the
early allocation, so pls. chime in with a +1, or if you must a -1 and explanation.

I'll do a +1 from the authors side.

The remaining requirements of RFC7120 for early allocations are AFAIK met.

Thanks!
    Toerless

---

From: Eliot Lear <[email-masked]>
Date: Thu, 2 Jul 2020 15:41:14 +0200

I have no objection.  My only caution is that otherName is poorly supported in the open source tool sets, but that is something we could conceivably work on.

Eliot

> On 2 Jul 2020, at 15:29, Toerless Eckert <[email-masked]> wrote:
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 2 Jul 2020 15:57:06 +0200

> I have no objection.  My only caution is that otherName is poorly supported in the open source tool sets, but that is something we could conceivably work on.

Thanks, i would count it towards the need for experimentation.

If there is explicit feedback that otherName will be less well implementable/deployable
than URI / "urn:ietf:params:acp:node:<AcpNodeName>", then i would at this
stage of the process probably still rather start a second 3 page normative
RFC that specifies the use of the URN Name for ACP as an alternative,
because after 6 years it would be a nice change not to further drag our
heels on the first ACP RFC.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Jul 2020 13:24:34 -0400

> required for the implementation, but the toolchain would require both if i understand it

If you use an ASN1 compiler for this, then yes.

If one does library calls to code that already processes otherName, then just
the IANA2 OID is needed, but I'm all for asking for both.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Jul 2020 13:29:07 -0400

Eliot Lear <lear=[email-masked]> wrote:
    > I have no objection.  My only caution is that otherName is poorly
    > supported in the open source tool sets, but that is something we could
    > conceivably work on.

I disagree!
otherName is adequately supported (if poorly documented) in openssl.cnf for our purposes.
Creating otherName SAN extensions from library interface is fully supported.

The openssl x509 -text output program does not know how to format arbitrary
otherName text, so it just says <unsupported>.

Here is an proprietary otherName that I created awhile ago, implemented in ruby:

      # the OID: 1.3.6.1.4.1.46930.1 is a Private Enterprise Number OID:
      #    iso.org.dod.internet.private.enterprise . SANDELMAN=46930 . 1
      @idevid.add_extension(extension_factory.create_extension(
                              "subjectAltName",
                              sprintf("otherName:1.3.6.1.4.1.46930.1;UTF8:%s",
                                      self.sanitized_eui64),
                              false))

The hardest part was figuring out the ";UTF8:" part, as I had to read the C
code underneath to learn how that worked.
(false, is I think, whether it is critical)

---

From: Eliot Lear <[email-masked]>
Date: Thu, 2 Jul 2020 19:51:54 +0200

> On 2 Jul 2020, at 19:29, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

Whereas for a URI it will actually provide you the URI.  Also, if the otherName is at all complex, the openssl.cnf file is entirely counter-intuitive.  This having been said, one needn’t write to OpenSSL’s limitations.

Eliot

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 2 Jul 2020 22:43:34 +0200

UTF8 ? ;-))

AcpNodeName ::= IA5String (SIZE (1..MAX))

To keep the encoding simple, there is no consideration for
internationalized acp-domain-names.  The acp-node-name is not
intended for end user consumption...

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Jul 2020 08:57:50 +1200

Yes please. We have a need for implementations ASAP, however long this spends in the RFC queue.

Regards
   Brian Carpenter

On 03-Jul-20 01:29, Toerless Eckert wrote:
> .

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Jul 2020 19:46:39 -0400

>> sprintf("otherName:1.3.6.1.4.1.46930.1;UTF8:%s",

I think it's just:

 @idevid.add_extension(extension_factory.create_extension(
    "subjectAltName",
    sprintf("otherName:1.3.6.1.4.1.46930.1;IA5STRING:%s",
    self.sanitized_eui64),
    false))

Although I think "IA5" and "IA5STRING" are equvivalent here.

    >> (false, is I think, whether it is critical)

The table is at: openssl/crypto/asn1/asn1_gen.c.  If it's in a document
somewhere, I never found it.

---

From: "Fries, Steffen" <[email-masked]>
Date: Fri, 3 Jul 2020 08:53:10 +0000

+1 

I consider going with otherNames for the ACP domain the safe way. Taking interactions with existing infrastructures into account may lead to potential misinterpretations of using other fields as the discussion has shown. Having a distinct allocation is more clear. 

Best regards
Steffen

> -----Original Message-----
> From: Anima <[email-masked]> On Behalf Of Toerless Eckert
> Sent: Donnerstag, 2. Juli 2020 15:29
> To: [email-masked]
> Cc: [email-masked]; Rob Wilton (rwilton) <[email-masked]>;
> [email-masked]
> Subject: [Anima] ANIMA-WG: pls chime in: early allocation for otherName
> code points (draft-ietf-anima-autonomic-control-plane)
> 
> ACP Revision -26 introduced a new otherName / AcpNodeName encoding
> for the ACP Domain Information (now call AcpNodeName / acp-node-name).
> Michael Richardson (and potentially other) implementors would like to
> update implementation to use this new encoding for interop testing, which
> requires allocation of two IANA code points (technically i think only one is
> required for the implementation, but the toolchain would require both if i
> understand it correctly).
> 
> The early allocation process RFC7120 requires to vet the community for
> interest in the early allocation, so pls. chime in with a +1, or if you must a -1
> and explanation.
>