Re: [Suit] [Rats] [sacm] CoSWID and EAT and CWT

"Smith, Ned" <ned.smith@intel.com> Tue, 03 December 2019 01:38 UTC

Return-Path: <ned.smith@intel.com>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089831200E9; Mon, 2 Dec 2019 17:38:33 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 G9ciyeVsvsTG; Mon, 2 Dec 2019 17:38:30 -0800 (PST)
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64957120033; Mon, 2 Dec 2019 17:38:30 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2019 17:38:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.69,270,1571727600"; d="scan'208,217";a="412003141"
Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by fmsmga006.fm.intel.com with ESMTP; 02 Dec 2019 17:38:29 -0800
Received: from orsmsx163.amr.corp.intel.com (10.22.240.88) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 2 Dec 2019 17:38:29 -0800
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.161]) by ORSMSX163.amr.corp.intel.com ([169.254.9.212]) with mapi id 14.03.0439.000; Mon, 2 Dec 2019 17:38:29 -0800
From: "Smith, Ned" <ned.smith@intel.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>
CC: "rats@ietf.org" <rats@ietf.org>, "suit@ietf.org" <suit@ietf.org>, sacm <sacm@ietf.org>
Thread-Topic: [Suit] [Rats] [sacm] CoSWID and EAT and CWT
Thread-Index: AQHVqTyPSn+xiLGOUUe3g1nv9QM4IKenoj8A
Date: Tue, 3 Dec 2019 01:38:28 +0000
Message-ID: <F7783A24-302A-4D6B-9030-9AFAD71E4597@intel.com>
References: <F23B6DE1-3343-4553-AF1C-832EA7B7B238@arm.com> <27435.1575305487@localhost> <CAHbuEH7t7qAiDRBOrRL0inqzB4htvyyPBrd-iT3kKcFN1=PdQg@mail.gmail.com>
In-Reply-To: <CAHbuEH7t7qAiDRBOrRL0inqzB4htvyyPBrd-iT3kKcFN1=PdQg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1f.0.191110
x-originating-ip: [10.24.10.58]
Content-Type: multipart/alternative; boundary="_000_F7783A24302A4D6B90309AFAD71E4597intelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/SgPwDqdHc3QiCtB_-sCVo9DOw1o>
Subject: Re: [Suit] [Rats] [sacm] CoSWID and EAT and CWT
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2019 01:38:33 -0000

EAT is a payload that can be exchanged between an Attester-Verifier or Verifier-RelyingParty.
[Co]SWID is a payload that can be exchanged between Endorser-Verifier or (possibly?) Attester-Verifier.

It is the latter use case context (Attester-Verifier) that is potentially confusing because it presumes the [Co]SWID payload should be wrapped by an EAT.

The architecture slides presented at Singapore showed Attester-Verifier interactions supporting multiple signed formats. Therefore, it could be reasonable to consider [Co]SWID as yet another payload format the Verifier needs to handle.

Another consideration might question whether it makes sense for [Co]SWID to be regarded as Evidence. Maybe it should be restricted to Endorsements?

The SWID documentation seems to suggest that SWID structures should be maintained on the Attester and updated when SW/FW updates occur. Possibly, the installer is working with two objects SUIT manifests and [Co]SWID structures keeping both maintained on the Attester? If this is the case, then it might make sense to consider unifying them? That might be the context for some of the list activity surrounding SUIT manifest and [Co]SWID?

The important distinction from the perspective of the RATS architecture is that Endorsements (signed by a mfg – aka “Endorser”) are still Endorsements even if they are stored on the Attester and conveyed to a Verifier over a conveyance protocol that supports conveyance of Evidence. Evidence and Endorsements are signed by different keys. How they are conveyed isn’t interesting to the Verifier per se. except where freshness is a consideration.
-Ned

From: Suit <suit-bounces@ietf.org> on behalf of Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Monday, December 2, 2019 at 10:16 AM
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "rats@ietf.org" <rats@ietf.org>rg>, "suit@ietf.org" <suit@ietf.org>rg>, sacm <sacm@ietf.org>
Subject: Re: [Suit] [Rats] [sacm] CoSWID and EAT and CWT



On Mon, Dec 2, 2019 at 11:51 AM Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr%2Bietf@sandelman.ca>> wrote:

Brendan Moran <Brendan.Moran@arm.com<mailto:Brendan.Moran@arm.com>> wrote:
    > Thanks for bringing this to my attention. I'm not sure that I
    > understand the goal of using a CWT for a CoSWID or a SUIT
    > manifest. Would you be able to elaborate on why we should use CWT?

I'm also in need of a diagram of how CoSWID and SUIT manifests and RATS EAT
interact.   I feel that the (optional) layer of signature in the CoSWID is
causing us to lose the forest for the trees...

I see why you might want a CoSWID or SWID in a CWT or EAT, but don't see the mapping for SUIT being preferred to CoSWID or SWID.

Best regards,
Kathleen

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca<mailto:mcr@sandelman.ca>  http://www.sandelman.ca/        |   ruby on rails    [




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



_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats


--

Best regards,
Kathleen