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

"Smith, Ned" <ned.smith@intel.com> Tue, 03 December 2019 21:32 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 CCCA2120044; Tue, 3 Dec 2019 13:32:06 -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 rtZWAzkejZV1; Tue, 3 Dec 2019 13:32:05 -0800 (PST)
Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) (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 2791312003E; Tue, 3 Dec 2019 13:32:05 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Dec 2019 13:32:04 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.69,275,1571727600"; d="scan'208";a="222973637"
Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by orsmga002.jf.intel.com with ESMTP; 03 Dec 2019 13:32:04 -0800
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.161]) by ORSMSX107.amr.corp.intel.com ([169.254.1.224]) with mapi id 14.03.0439.000; Tue, 3 Dec 2019 13:32:04 -0800
From: "Smith, Ned" <ned.smith@intel.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: "rats@ietf.org" <rats@ietf.org>, "suit@ietf.org" <suit@ietf.org>, "Henk Birkholz" <henk.birkholz@sit.fraunhofer.de>, sacm <sacm@ietf.org>
Thread-Topic: [Suit] [sacm] [Rats] CoSWID and EAT and CWT
Thread-Index: AQHVqh3FKY8nS4BEAEucOvvSkwG9zqeo7fmA
Date: Tue, 3 Dec 2019 21:32:03 +0000
Message-ID: <BCBEE59A-E4A2-46CA-9A3B-05EC23522524@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> <40A05013-D12A-4D16-9FE9-2E97D5D8EF90@intel.com> <27974.1575407275@localhost>
In-Reply-To: <27974.1575407275@localhost>
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.102]
Content-Type: text/plain; charset="utf-8"
Content-ID: <6A9A528D190A98448C8A2F6F624C09BA@intel.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/vt2fP7tNFpDiS6KJCfZVtm8WskI>
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 21:32:07 -0000


´╗┐On 12/3/19, 1:08 PM, "Suit on behalf of Michael Richardson" <suit-bounces@ietf.org on behalf of mcr+ietf@sandelman.ca> wrote:

    
    
    Smith, Ned <ned.smith@intel.com> wrote:
        > 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).
    
    I believe that unsigned CoSWID structures will be inside another signed
    structure (such as a SUIT manifest), will be conveyed by secure transport
    (i.e. HTTPS or CoAPS transport of a RESTCONF mechanism that retrieves it), or
    will be stored in a trusted database.
    
    So, I agree with you that unsigned CoSWID objects in the wild would be
    invalid and unusual.
[nms] The unsigned CoSWID that is enveloped by something else that is signed may not be the same as a CoSWID that is (directly) signed because the signing keys could differ. The Verifier should care not only about who asserts the CoSWID but also whether or not that entity is authorized (most authoritative entity) to make the assertion. Even if some other layer 'signs' it, it could still be invalid.
    
        > 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.
    
    I'm a bit uncomfortable with the idea that a CoSWID signed by an Attester is
    the way that an Attester indicates what software release it is running.
    I would prefer that the structure was instead:
       EAT{protected_map{measurement-of-running-firmware=XX}
           S_endorser{firmware_version=YY,measurement=XX}}
    
    That is, the CoSWID provided by as part of the Evidence would echo the
    Endorsement. Of course, the Verifier would still have to be able to verify
    the endorser's key, but having done so, it now can consider the policy
    question: "is firmware_version YY new enough?"

[nms] Agree. CoSWID is good at saying M=(S_endorser{firmware_version=YY,measurement=XX}). Verifier doesn't necessarily care if M arrives as an EAT map (above) or some other way. Verifier might care that Attester knew that measurement-of-running-firmware matches M if Attester is also doing Verified Boot or is trusted in some way to make sure XXs match. Simply constructing the map doesn't imply the Attester did the other checks unless there is a specification that mandates the check as a condition of forming the map structure.
    
        > 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.
    
    I think that we are in violent agreement here.
    
    --
    ]               Never tell me the odds!                 | ipv6 mesh networks [
    ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
    ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
    
    
    --
    Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
     -= IPv6 IoT consulting =-