IETF Logo Mail Archive

Re: [Rats] EAT Profiles

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 19 September 2022 16:25 UTC

Return-Path: <mcr@sandelman.ca>
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 D2077C14CE2B for <rats@ietfa.amsl.com>; Mon, 19 Sep 2022 09:25:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Kozx7az3SQAv for <rats@ietfa.amsl.com>; Mon, 19 Sep 2022 09:25:01 -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) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA240C14CE26 for <rats@ietf.org>; Mon, 19 Sep 2022 09:25:01 -0700 (PDT)
Received: from dooku.sandelman.ca (dynamic-089-014-037-053.89.14.pool.telefonica.de [89.14.37.53]) by relay.sandelman.ca (Postfix) with ESMTPS id E6BDB1F455; Mon, 19 Sep 2022 16:24:58 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 336F51A0FCB; Mon, 19 Sep 2022 18:24:58 +0200 (CEST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Carl Wallace <carl@redhoundsoftware.com>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "rats@ietf.org" <rats@ietf.org>
In-reply-to: <73263C15-D995-404D-843D-13C2ED4B0BC5@redhoundsoftware.com>
References: <71934.1663019954@dooku> <DBBPR08MB5915AC23726BF997EB9E44C4FA489@DBBPR08MB5915.eurprd08.prod.outlook.com> <19805.1663344806@dooku> <AS8PR08MB5911DB2FE9608541698983B0FA4D9@AS8PR08MB5911.eurprd08.prod.outlook.com> <636099.1663593501@dooku> <73263C15-D995-404D-843D-13C2ED4B0BC5@redhoundsoftware.com>
Comments: In-reply-to Carl Wallace <carl@redhoundsoftware.com> message dated "Mon, 19 Sep 2022 07:11:17 -0700."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 27.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 19 Sep 2022 18:24:58 +0200
Message-ID: <837335.1663604698@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/2A6HOwDWvPwcZnUQBIjYfgD5P9U>
Subject: Re: [Rats] EAT Profiles
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, 19 Sep 2022 16:25:03 -0000

Carl Wallace <carl@redhoundsoftware.com> wrote:
    CW> This does not follow from Hannes' statement. Another vendor may use
    CW> some library to produce EATs for their profile and yet another vendor
    CW> may use the same library to produce EATs for a different
    CW> profile. From elsewhere in the threads, I also do not see why a
    CW> cookbook of profiles (i.e., your yellow, brown, red, etc. examples)
    CW> could not be produced referencing EAT as a base specification.

It could be produced, but it actually would be difficult for many entities to procure.
Being able to say, in an RFP, "RFCXXXX Yellow Profile" would be perfectly
acceptable to international trade agreements.   The users of the profiles
that become RFCs will also be relative easy.   Then the waters get murky when we get
to other profiles that might only be published by vendors and consortia.
They don't have standing in trade agreements... some ITU types claim that
RFCs actually don't count.

Anyway, in every other security area, we have looked at multiplicity of
options and decide that we don't want every option.  We've gone to either
crypto suites being explicit, or UI suites where we don't present the user
with all possible options.

I'm just asking for the same thing.

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

v2.23.0 | Report a Bug | By Email