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

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Tue, 03 December 2019 13:09 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
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 6419312002E; Tue, 3 Dec 2019 05:09:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 I9fd15391iSA; Tue, 3 Dec 2019 05:09:09 -0800 (PST)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 1C51F120043; Tue, 3 Dec 2019 05:09:08 -0800 (PST)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id xB3D95fR032340 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Tue, 3 Dec 2019 14:09:06 +0100
Received: from [192.168.16.50] (79.234.126.215) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Tue, 3 Dec 2019 14:09:00 +0100
To: Michael Richardson <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>, "suit@ietf.org" <suit@ietf.org>, sacm <sacm@ietf.org>
References: <F23B6DE1-3343-4553-AF1C-832EA7B7B238@arm.com> <27435.1575305487@localhost> <CAHbuEH7t7qAiDRBOrRL0inqzB4htvyyPBrd-iT3kKcFN1=PdQg@mail.gmail.com> <F7783A24-302A-4D6B-9030-9AFAD71E4597@intel.com> <19794.1575378270@localhost>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <6a18b426-b11f-82e5-8758-93f79360b2a4@sit.fraunhofer.de>
Date: Tue, 03 Dec 2019 14:09:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <19794.1575378270@localhost>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.234.126.215]
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/vjjRvtVK99yHvgHrdy6uuUo22YY>
Subject: Re: [Suit] [sacm] [Rats] 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 13:09:11 -0000

As the I-D is trying to stay close to the ISO/IEC spec & as COSE is an 
"envelope" encapsulating a CoSWID tag, the guidance on signing is 
actually a bit detached to the structure of a CoSWID.

Having said that. CoSWID can be measurements of installed SW components 
on an Attester and be part of Attestation Evidence. For this, they do 
not have to be signed - this depends on the level of assurance the 
Attest-ING Environment of the Attester can provide (e.g. via 
Endorsements from Endorsers, formerly known as Asserters).

On 03.12.19 14:04, Michael Richardson wrote:
> 
> Smith, Ned <ned.smith@intel.com> wrote:
>      > 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.
> 
> That's an interesting take on things.
> My reading of CoSWID is that COSE signatures are almost an afterthought
> (appendix A), and in any case, would be produced by manufacturers rather than
> as evidence.
> 
> It seems that inclusion of an unsigned CoSWID into a SUIT Manifest is
> appropriate as the manufacturer is authoritative for both.
> 
>      > Another consideration might question whether it makes sense for [Co]SWID to
>      > be regarded as Evidence. Maybe it should be restricted to Endorsements?
> 
> I think that it makes more sense as Endorsement only, as such it falls
> outside of the normative part of the RATS architecture.
> 
>      > 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.
> 
> If the manufacturer-signed Endorsement is communicated within EAT, then it's
> not a seperate token format. It's just payload for a Evidence carrying EAT.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
> 
> 
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm
>