Re: [Suit] New preliminary information model draft
Carsten Bormann <cabo@tzi.org> Thu, 14 June 2018 11:29 UTC
Return-Path: <cabo@tzi.org>
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 E2BFE13112C for <suit@ietfa.amsl.com>; Thu, 14 Jun 2018 04:29:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 n1p60uvMQqwY for <suit@ietfa.amsl.com>; Thu, 14 Jun 2018 04:29:24 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 97E5613112F for <suit@ietf.org>; Thu, 14 Jun 2018 04:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w5EBTHhA006457; Thu, 14 Jun 2018 13:29:18 +0200 (CEST)
Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4161bx1HnFzDXPT; Thu, 14 Jun 2018 13:29:17 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <B666680F-0BFF-4D7C-BA8A-B9A3CCB34FC0@tzi.org>
Date: Thu, 14 Jun 2018 13:29:16 +0200
Cc: suit <suit@ietf.org>
X-Mao-Original-Outgoing-Id: 550668555.254382-8de144290b2404b54f93c2d11cfe6f0b
Content-Transfer-Encoding: quoted-printable
Message-Id: <B0EA308F-2719-404A-892B-EFE9CDB46BB7@tzi.org>
References: <A48809A5-E7CE-4404-B39D-A1702C672923@arm.com> <B666680F-0BFF-4D7C-BA8A-B9A3CCB34FC0@tzi.org>
To: Brendan Moran <Brendan.Moran@arm.com>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/OwjjxDpwaitMxtX2potnFpEzhk4>
Subject: Re: [Suit] New preliminary information model draft
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 14 Jun 2018 11:29:26 -0000
A few more items (some editorial): "optional to implement" -- do we need to talk about protocol evolution (extensibility), specifically about ignorable (elective) and mandatory (critical) elements? * referencing RFC 4122: cite in 4.3 * why are we using pre-RFC5378 boilerplate? * The "use UTC as serial" text is a hint for implementers/users, not part of the information model. * Confidential Information Disclosures (what is confidential?) -> Disclosures of Confidential Information * "version" (an identifier space implying some form of ordering) vs. "identifier" (no such implication) * "last application time" -- the time this was last applied? Grüße, Carsten > On Jun 14, 2018, at 13:15, Carsten Bormann <cabo@tzi.org> wrote: > > I believe MFT10 and its mitigations still confuse > > — is the sender *authorized* to make claims about the firmware image at hand for device X > — does the sender *intend* to make a claim about this firmware destined for device X > > The first one can be supported by ACLs. > But the sender may very well be authorized to make a claim, it may just not want to, pertaining to device X. > > In general, signed claims may need destination verification. > > In a CWT, this is often done with the “aud” claim field. > I have not made up my mind if something like that is enough here as well or we need something more well structured for destination verification. > > Grüße, Carsten > > > >> On Jun 13, 2018, at 16:23, Brendan Moran <Brendan.Moran@arm.com> wrote: >> >> I have uploaded a new information model draft to the suit-wg repo: >> https://github.com/suit-wg/information-model/blob/v01/draft-ietf-suit-information-model.md >> >> You can see the diff using Github’s comparison tool: >> https://github.com/suit-wg/information-model/compare/master...v01 >> >> Best Regards, >> Brendan >> >> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. >> _______________________________________________ >> Suit mailing list >> Suit@ietf.org >> https://www.ietf.org/mailman/listinfo/suit > > >
- Re: [Suit] New preliminary information model draft Carsten Bormann
- Re: [Suit] New preliminary information model draft Carsten Bormann
- Re: [Suit] New preliminary information model draft Carsten Bormann
- [Suit] New preliminary information model draft Brendan Moran