IETF Logo Mail Archive

Re: [Rats] Should we remove submods from EAT? (was Re: EAT Review Comments)

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 16 December 2021 15:11 UTC

Return-Path: <mcr+ietf@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 86DD43A1000 for <rats@ietfa.amsl.com>; Thu, 16 Dec 2021 07:11:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
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 lLw5XfQBV_wj for <rats@ietfa.amsl.com>; Thu, 16 Dec 2021 07:11:23 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE613A0FFD for <rats@ietf.org>; Thu, 16 Dec 2021 07:11:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7754738F1F; Thu, 16 Dec 2021 10:15:36 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Idm_m0pCmbFF; Thu, 16 Dec 2021 10:15:35 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D215538F1E; Thu, 16 Dec 2021 10:15:35 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1639667735; bh=3KpqYVG9t+WE/4XYaPEjOfu+Cj/+A2aXsYWjv8hekEY=; h=From:To:Subject:In-Reply-To:References:Date:From; b=v0EBkTyGph9hzEKd8J4nVMcXzlTPzBE8UPUQfaiG0NMHe8+el90BtGlMNyFg5x+Fb 6775BYsHZiD8tzsGeQaVWq8wcl1g83XM6K73796LVlqBN+nu7Sgze2/KEfw/9fWbf0 UVDxxAKA73yybLC6dkuiPhDIrgmGG3NHLeuNi8MPfAMSoL0/gsvdEqyb91UlueAhfx L3VacBre5xZkyCQY/SZVZxeTUaS4HnXhx/uXQIdBhx0NAtNwJxTlfEsXm3CC7v5D+8 KyvvR58Y3lGNnkqXJiyX6txUhu4FpvsSQ+YrmYsKuhUQRDgEzJqjjKdrCIYhnFqd0+ MHYWg52EOlc1g==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 554241B9; Thu, 16 Dec 2021 10:11:21 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Smith, Ned" <ned.smith@intel.com>, Laurence Lundblade <lgl@island-resort.com>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "rats@ietf.org" <rats@ietf.org>
In-Reply-To: <ABD665F5-777E-4A9C-8920-0135FA91FC7B@intel.com>
References: <DBBPR08MB59150EEE386E675005A52124FA6E9@DBBPR08MB5915.eurprd08.prod.outlook.com> <B81765CF-8515-440B-A021-977FCD59D5E2@island-resort.com> <DBBPR08MB5915DD8BAA394E7D665E4C7DFA709@DBBPR08MB5915.eurprd08.prod.outlook.com> <E6E179AD-23AA-4B22-A0CE-26BED6BB2862@island-resort.com> <ABD665F5-777E-4A9C-8920-0135FA91FC7B@intel.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: Thu, 16 Dec 2021 10:11:21 -0500
Message-ID: <10720.1639667481@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/gLCj8z05qQBh5hK3di9EyotOuEw>
Subject: Re: [Rats] Should we remove submods from EAT? (was Re: EAT Review Comments)
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 16 Dec 2021 15:11:29 -0000

Smith, Ned <ned.smith@intel.com> wrote:
    > There has been discussion that EAT as a standalone spec can’t
    > reasonably be implemented without a profile. Possibly, the profile
    > context addresses some of these concerns? The PSA draft goes further to
    > define a profile, but I don’t see it directly addressing the
    > consideration for multi-vendor device composition.

That's unfortunate if that is really the case.  Profiles of profiles of profiles.
I think of EAT as the profile of COSE that let's us do attestation.
If there is a profile, then it would address the naming concern that you
raised.

In general, I think that every single vendor/integrator who puts the right
manufacturer supports (Endorsements, Reference Values) and/or operates a
Verifier (likely in Background Check model) will need to solve the naming and
profile problem.    I'm not sure that we need standardization here: it's all
under control of the manufacturer.

    > The other EAT claims (not submod) seem to imply a simple composition
    > where the thing (module) to which the CWT/JWT is issued / bound is the
    > thing (module) that has the EAT claim.

I would prefer that the EAT document was simplified/shortened, that anything
we do not presently have running code for be removed to another document.
I'd like to see EAT published by Summer 2022, even if that means four or five
extension documents come later.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.39.1 | Report a Bug | By Email | System Status