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

[Hannes Tschofenig <[e-mail]>]

Hi Michael,

here is my take on this issue: I don't think that the idea of having
multiple parties sign the manifest so that the device can check all the
signatures in order to decide whether the vendor, enterprise operator,
and regulator "agreed" on deploying a specific firmware update for a
medical device. I think that this is a too heavy for an IoT device and
too much policy for the device to consider. While this is not impossible
to do (even with the proposed manifest format) I believe it is more
likely that the party providing the firmware update to the IoT device
will make that policy decision (which will typically involve humans).

Hence, I think we need to make sure that the common case works well. If
someone wants to do research on the other option that's fine for me as
well.

Ciao
Hannes


On 08/22/2017 07:18 PM, Michael Richardson wrote:
> 
> Hannes Tschofenig <[e-mail]> 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
> update.
> (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
>     >> [e-mail] https://www.ietf.org/mailman/listinfo/fud
>     >>
> 
>     > _______________________________________________ Fud mailing list
>     > [e-mail] https://www.ietf.org/mailman/listinfo/fud
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> _______________________________________________
> Fud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/fud
>