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

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

Return-Path: <ned.smith@intel.com>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE15D1200CC; Tue, 3 Dec 2019 08:12:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 UcIM5kHwbf0O; Tue, 3 Dec 2019 08:12:20 -0800 (PST)
Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (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 BC6731200A1; Tue, 3 Dec 2019 08:12:20 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Dec 2019 08:12:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.69,273,1571727600"; d="scan'208";a="208495110"
Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by fmsmga008.fm.intel.com with ESMTP; 03 Dec 2019 08:12:20 -0800
Received: from orsmsx115.amr.corp.intel.com (10.22.240.11) by ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 3 Dec 2019 08:12:20 -0800
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.161]) by ORSMSX115.amr.corp.intel.com ([169.254.4.121]) with mapi id 14.03.0439.000; Tue, 3 Dec 2019 08:12:19 -0800
From: "Smith, Ned" <ned.smith@intel.com>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Michael Richardson <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>, "suit@ietf.org" <suit@ietf.org>, sacm <sacm@ietf.org>
Thread-Topic: [Suit] [sacm] [Rats] CoSWID and EAT and CWT
Thread-Index: AQHVqdrh3qFLtHXJaU+liEJBo3ckJ6eolSgA
Date: Tue, 03 Dec 2019 16:12:19 +0000
Message-ID: <40A05013-D12A-4D16-9FE9-2E97D5D8EF90@intel.com>
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> <6a18b426-b11f-82e5-8758-93f79360b2a4@sit.fraunhofer.de>
In-Reply-To: <6a18b426-b11f-82e5-8758-93f79360b2a4@sit.fraunhofer.de>
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.254.183.12]
Content-Type: text/plain; charset="utf-8"
Content-ID: <E54B7963CEFA5549A904354FBA3735F8@intel.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/rV3RvIaS5RokNi7ScQ9T8GlXMSo>
Subject: Re: [sacm] [Suit] [Rats] CoSWID and EAT and CWT
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2019 16:12:23 -0000

Henk,
I'm not clear if you are saying that an unsigned CoSWID is assumed to be a statement from an Attest-ING environment or something else. Normally, I regard unsigned assertions as invalid (verifiers should not make assumptions). 

CoSWID structures can be signed by either Attesters (Attesting env) or Endorsers. The CoSWID formatting is the same but the signers are different and a Verifier might treat the CoSWID content differently based on who signed it. For example, if an Attester signed it then a Verifier would expect to find an Endorser signed CoSWID with which to compare to Evidence. 

Enveloping formats (e.g. EAT[CoSWID] ) doesn't disambiguate who signed what. Both the EAT thing and the CoSWID thing could be signed and by different signers. Alternatively, neither of them could be signed. If the latter, then both the EAT and CoSWID things are invalid.
-Ned

On 12/3/19, 5:09 AM, "Suit on behalf of Henk Birkholz" <suit-bounces@ietf.org on behalf of henk.birkholz@sit.fraunhofer.de> wrote:

    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
    > 
    
    _______________________________________________
    Suit mailing list
    Suit@ietf.org
    https://www.ietf.org/mailman/listinfo/suit