IETF Logo Mail Archive

Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 01 July 2020 01:34 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAB73A08AA for <anima@ietfa.amsl.com>; Tue, 30 Jun 2020 18:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCZRKdxQVI51 for <anima@ietfa.amsl.com>; Tue, 30 Jun 2020 18:34:14 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E800F3A08A5 for <anima@ietf.org>; Tue, 30 Jun 2020 18:34:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 33BDF389BC for <anima@ietf.org>; Tue, 30 Jun 2020 21:31:25 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 80-_f4OzKOrP for <anima@ietf.org>; Tue, 30 Jun 2020 21:31:24 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 70E8B389BB for <anima@ietf.org>; Tue, 30 Jun 2020 21:31:24 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8E146476 for <anima@ietf.org>; Tue, 30 Jun 2020 21:34:11 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Anima WG <anima@ietf.org>
In-Reply-To: <69B9B7B6-4B75-4336-9F3F-45CD4FA51291@cisco.com>
References: <FB6127DD-A111-4E40-A095-5E3C03AA6660@vigilsec.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <FF181E1F-2B93-47BB-AB45-7F66D880108B@vigilsec.com> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <CABcZeBN_tQgH8ZZmVg82h8-cthm0uQ6b846N71G9NYFSxdUMRQ@mail.gmail.com> <e84cc89e-6503-7cd7-4281-9cf4629a7bb7@gmail.com> <3A5D70B2-B3F9-42A6-9219-F25D657A7A7F@vigilsec.com> <20200628161149.GA16571@faui48f.informatik.uni-erlangen.de> <20200630161004.GA48194@faui48f.informatik.uni-erlangen.de> <69B9B7B6-4B75-4336-9F3F-45CD4FA51291@cisco.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 30 Jun 2020 21:34:11 -0400
Message-ID: <23063.1593567251@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/d3L7TOaoat72JH-8vYwgUkujONg>
Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2020 01:34:15 -0000

Eliot Lear <lear@cisco.com> wrote:
    > I think either a URI or otherName are pretty much functionally
    > equivalent.  I might go with URI for one particular reason, which is
    > that the tooling – in particular OpenSSL – will handle it better.

Maybe the command line stuff, but for the API, it's an identical amount of
effort. (I have running code).

I don't think an ASN.1 encoded otherName will be better for IoT (or BFRS)
because it force the ACP application developers to learn something about
ASN.1, and history says they will get it wrong. (Because, as Nico says, lack
of access to ASN1 code generators).

I would prefer CBOR encoding, if there is consensus that it should not be a string.
This also anticipates more modern certificate-like artifacts (CoID).

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email