Re: [Anima] FW: New Version Notification for draft-mohammed-anima-voucher-security-profile-00.txt

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 30 May 2023 16:12 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 D9D14C1522C8 for <anima@ietfa.amsl.com>; Tue, 30 May 2023 09:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx2HuM0FebmN for <anima@ietfa.amsl.com>; Tue, 30 May 2023 09:12:00 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1222C1519B6 for <anima@ietf.org>; Tue, 30 May 2023 09:12:00 -0700 (PDT)
Received: from dyas.sandelman.ca (unknown [142.169.16.11]) by relay.sandelman.ca (Postfix) with ESMTPS id 6922D1F45B; Tue, 30 May 2023 16:11:59 +0000 (UTC)
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id 5AE38A635B; Tue, 30 May 2023 18:11:46 +0200 (CEST)
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 5824DA1EC4; Tue, 30 May 2023 12:11:46 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Srihari Raghavan (srihari)" <srihari=40cisco.com@dmarc.ietf.org>
cc: "anima@ietf.org" <anima@ietf.org>, "jabir Mohammed (jamohamm)" <jamohamm@cisco.com>, "Reda Haddad (rehaddad)" <rehaddad@cisco.com>, "Sandesh Rao (sandeshr)" <sandeshr@cisco.com>
In-reply-to: <78D5263E-C7B4-40A8-91E3-949B78DD801C@cisco.com>
References: <168543538755.57544.11025538238647976477@ietfa.amsl.com> <78D5263E-C7B4-40A8-91E3-949B78DD801C@cisco.com>
Comments: In-reply-to "Srihari Raghavan \(srihari\)" <srihari=40cisco.com@dmarc.ietf.org> message dated "Tue, 30 May 2023 08:48:25 -0000."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 30 May 2023 12:11:46 -0400
Message-ID: <3427308.1685463106@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/BqRQiHysQTWIjRnOqaiv1taT9Hk>
Subject: Re: [Anima] FW: New Version Notification for draft-mohammed-anima-voucher-security-profile-00.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 30 May 2023 16:12:01 -0000

In the ID, you write:

} 5. Changes to Registrar Behavior
} The Registrar is the component that authenticates the pledge, makes
} authorization decisions, and distributes vouchers. If the extensions are
} supported, the Registrar MAY process a security profile selector request from
} owner that identifies what underlying security parameters need to be enabled
} in the security-profile-selector send down to the pledge as part of these
} extensions.

1. You haven't understood how vouchers are used.  The Registrar does not
   create them.

2. Unfortunately, the result of the year+ effort to provide a way to
   incrementally extend RFC8366 has failed due to limitations in YANG.
   Under the hood, it ought to be trivial to do in the JSON or CBOR.
   RFC8366bis simply revises the module as a whole, and your extension would
   have to go into 8366bis, if it made sense.

3. 32 is not enough bits.  Using bits is probably a failure.
   Probably you need an IANA registry of posture definitions, and it probably
   needs to have an integer per item.  There is probably need to have vendor
   extensions, probably by PEN.





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