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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 03 December 2019 13:04 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 EBD7812002E; Tue, 3 Dec 2019 05:04:37 -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 lrYdvaewDSsV; Tue, 3 Dec 2019 05:04:33 -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 6CCB8120019; Tue, 3 Dec 2019 05:04:32 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6476E3818F; Tue, 3 Dec 2019 08:00:55 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E37484AD; Tue, 3 Dec 2019 08:04:30 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "rats\@ietf.org" <rats@ietf.org>, "suit\@ietf.org" <suit@ietf.org>, sacm <sacm@ietf.org>
In-Reply-To: <F7783A24-302A-4D6B-9030-9AFAD71E4597@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>
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 08:04:30 -0500
Message-ID: <19794.1575378270@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/y6jRl_RMpLaCJjnsW5O88-Ow_r0>
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 13:04:38 -0000

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>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-