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

From: "Thomas Eichinger" <[email-masked]>
Date: Thu, 10 Aug 2017 15:37:00 -0700

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 14 Aug 2017 09:13:39 -0400

Yes, it makes sense to include that.

I was wondering why you put all of the key management into the spec, instead of defining a manifest content type that is carried inside EnvelopedData.  That would cover every form of key management that you care about.  This is the approach that was used in RFC 6486, although they only care about encapsulation in SignedData.

Russ

> On Aug 10, 2017, at 6:37 PM, Thomas Eichinger <[email-masked]> wrote:
> 
> Hi,
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 22 Aug 2017 13:33:14 +0200

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.

Ciao
Hannes

On 08/11/2017 12:37 AM, Thomas Eichinger wrote:
> _______________________________________________
> Fud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fud
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Aug 2017 13:18:46 -0400

> environments the firmware updates are most likely facing fewer

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)

    >> 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
    >> [email-masked] https://www.ietf.org/mailman/listinfo/fud
    >>

    > _______________________________________________ Fud mailing list
    > [email-masked] https://www.ietf.org/mailman/listinfo/fud

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-