[Rats] draft-ietf-rats-eat: bundles, CBOR

Christian Amsüss <christian@amsuess.com> Mon, 04 September 2023 21:37 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E7DC151081 for <rats@ietfa.amsl.com>; Mon, 4 Sep 2023 14:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 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, T_SCC_BODY_TEXT_LINE=-0.01] 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 Si-1GSOut7y7 for <rats@ietfa.amsl.com>; Mon, 4 Sep 2023 14:37:39 -0700 (PDT)
Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14BB2C151072 for <rats@ietf.org>; Mon, 4 Sep 2023 14:37:37 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by smtp.akis.at (8.17.1/8.17.1) with ESMTPS id 384LbZU5006193 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <rats@ietf.org>; Mon, 4 Sep 2023 23:37:35 +0200 (CEST) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host 095129206250.cust.akis.net [95.129.206.250] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 2F35C28ACD for <rats@ietf.org>; Mon, 4 Sep 2023 23:37:35 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:52c5:96b6:4737:debd]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 206CB286D6 for <rats@ietf.org>; Mon, 4 Sep 2023 23:37:35 +0200 (CEST)
Received: (nullmailer pid 11206 invoked by uid 1000); Mon, 04 Sep 2023 21:37:34 -0000
Date: Mon, 04 Sep 2023 23:37:34 +0200
From: Christian Amsüss <christian@amsuess.com>
To: rats@ietf.org
Message-ID: <ZPZOHvy5+c22QR3O@hephaistos.amsuess.com>
References: <RT-Ticket-1280210@icann.org> <rt-5.0.3-419252-1693849063-137.1280210-9-0@icann.org> <rt-5.0.3-419212-1693849492-125.1280210-9-0@icann.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="QJaAj38uHnTAAziD"
Content-Disposition: inline
In-Reply-To: <rt-5.0.3-419212-1693849492-125.1280210-9-0@icann.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/YggizlyVoCqua5kYkBZdVtZ2RRI>
Subject: [Rats] draft-ietf-rats-eat: bundles, CBOR
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Sep 2023 21:37:41 -0000

Hello RATS WG,

while reading the relevant parts of rats-eat to process the IANA
request for CBOR tag 602, I stumbled over what is probably just an
editorial thing:

* In Section 5 it says "The second part is a map/object as follows:",
  but what follows describes the values of the map, not the map itself.
  The map keys are only mentiojned two paragraphs below. This would at
  least need some "values of" sprinkled in, but it's probably more
  readable to pull text on the "label/name" up into the "The second
  part" list.

* "URIs are not the URI tag": "URIs are not *wrapped in* the URI tag"?

And one thing that's not editorial, and possibly just too late in the
process:

* manifest-format uses an array for a (content-format, encoded data)
  tuple. There is a different  way of encoding this published in
  RFC9277: A range of about 2**16 tags has been allocated, so that
  instead of `manifest-format = [ content-type, body ]`, `message-format =
  #6.(TN(content-type))(body)` could be used.

  I know too little of the EAT messages to fully assess whether this
  would work out in this case, but unless the format is set already in
  stone, I'd encourage you to have a look at the range registered in
  9277.

BR
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom