Re: [Fud] Comment on draft-moran-fud-manifest-00

Michael Richardson <> Tue, 22 August 2017 17:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5B211323B5 for <>; Tue, 22 Aug 2017 10:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CXcuBWKJCWO8 for <>; Tue, 22 Aug 2017 10:19:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C1FFC1323AB for <>; Tue, 22 Aug 2017 10:19:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id EA9D31F905 for <>; Tue, 22 Aug 2017 17:19:10 +0000 (UTC)
Received: by (Postfix, from userid 179) id 05813296A; Tue, 22 Aug 2017 19:18:46 +0200 (CEST)
From: Michael Richardson <>
In-reply-to: <>
References: <> <>
Comments: In-reply-to Hannes Tschofenig <> message dated "Tue, 22 Aug 2017 13:33:14 +0200."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 22 Aug 2017 13:18:46 -0400
Message-ID: <>
Archived-At: <>
Subject: Re: [Fud] Comment on draft-moran-fud-manifest-00
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: FUD - Firmware Updating Description <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Aug 2017 17:19:16 -0000

Hannes Tschofenig <> wrote:
    > Hi Thomas,

    > interesting idea.

    > As an optional feature I don't see a problem with it.

    > How exactly the approval process for applying a firmware update in a
    > particular product looks like will of course vary a lot. At the IOTSU
    > workshop we had people describing a healthcare setting where any code
    > changes need to go through certification first. In smart home
    > environments the firmware updates are most likely facing fewer
    > regulatory restrictions.

I think that the regulated (e.g. health-care) situation is different than
the security vs feature update situation.

In the regulated situation, I can see two ways to go about the process:
  a) devices have a built-in policy that requires signatures from X,Y and Z
     before they will apply them.

  b) devices have a built-in policy that will accept updates on from Z
     (the regulator)
     Z has a policy where it only reviews things once X and Y
     have signed.  Applying the signature from Z may remove the signature
     from X and Y (that's a space optimization only).
     As the device does not recognize X or Y, it would ignore those signatures.

Whereas, Thomas is suggesting that when any of X, Y or Z signs, it would
include some kind of flag (probably an OID?) saying the reason for the
(Maybe we'd want to also have optional space for a URL pointing at update notes)

    > On 08/11/2017 12:37 AM, Thomas Eichinger wrote:
    >> Hi,
    >> reading draft-moran-fud-manifest-00 I am wondering what people think
    >> about adding a component to the manifest classifying the described
    >> update as a security and/or feature update (others are imaginable) in
    >> a machine-readable manner.
    >> The use case I see is that users then can define rules to deploy
    >> security only updates in an automated timely fashion while being able
    >> to review others before. Similar to Directive.applyImmediately but not
    >> forced by the Author of the update.
    >> Any opinions on that?
    >> Best, Thomas
    >> _______________________________________________ Fud mailing list

    > _______________________________________________ Fud mailing list

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-