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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 03 December 2019 21:08 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 D67C512003E; Tue, 3 Dec 2019 13:08:00 -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 AwqNB-NoQD7X; Tue, 3 Dec 2019 13:07:58 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28BBB12002F; Tue, 3 Dec 2019 13:07:57 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C37783818F; Tue, 3 Dec 2019 16:04:19 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C32E6784; Tue, 3 Dec 2019 16:07:55 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Smith\, Ned" <ned.smith@intel.com>
cc: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "rats\@ietf.org" <rats@ietf.org>, "suit\@ietf.org" <suit@ietf.org>, sacm <sacm@ietf.org>
In-Reply-To: <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> <40A05013-D12A-4D16-9FE9-2E97D5D8EF90@intel.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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-sha256; protocol="application/pgp-signature"
Date: Tue, 03 Dec 2019 16:07:55 -0500
Message-ID: <27974.1575407275@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/MrHVZH0R5hbLTHsWPqYMC4mSXxg>
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:08:01 -0000


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.

    > 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?"

    > 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 =-