Subject: [Suit] Approval of Firmware Update

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Feb 2018 13:44:00 +0000

Hi all,

yesterday we also spoke about the co-signing / approving a firmware update through a party other than the author producing the firmware.
For this purpose I created another drawing and also introduced another role, namely the "approver". (Suggestion for better terminology is welcome.)

Whether the actual solution requires co-signing or some other form of approval is a separate question.

              /------------\                /------------\
             //------------\\              //------------\\
            //  Co-Signed/  \\            //  Co-Signed/  \\
            ||  Approved    ||            ||  Approved    ||
            \\  Manifest    //            \\  Manifest    //
             \\------------//+-----------+ \\------------//
+--------+   \------------/ |           |  \------------/ +--------+
|        |<.................| Untrusted |<................|        |
| Device |                  | Storage   |                 |Approver|
|        |                  |           |                 |        |
+--------+                  +-----------+                 +--------+
                                                               ^
                                                               .
                                                               .
                                                               .
                                              /------------\   .
                                             /              \  .
                                             |   Manifest   |  .
                                             \              /  .
                                              \------------/   .
                                                               .
                                                               .
                                                               .
                                                               .
                                                           +--------+
                                                           |        |
                                                           | Author |
                                                           |        |
                                                           +--------+

How does this look like? Does this address the feedback during the meeting yesterday?

Ciao
Hannes

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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Feb 2018 13:37:48 -0500

Hannes Tschofenig <[email-masked]> wrote:
    > yesterday we also spoke about the co-signing / approving a firmware
    > update through a party other than the author producing the firmware.

Good.

    > For this purpose I created another drawing and also introduced another
    > role, namely the “approver”. (Suggestion for better terminology is
    > welcome.)

In my mind, the should really only be the approver, and there should
probably only be one signature that the end device looks for.

I think that all the complex situations we want (author signs firmware,
reviewer signs it, plant operation signs it, operator signs it for
odd-numbered devices...) should really about how the device goes from the
built-in trust anchors to the authoritative entity.  It could be that we
can use SAML or SPKI or ??? for this.

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 27 Feb 2018 16:32:30 -0500

Hannes:

Why not signer?  The quality control / release process will be different in many situations, but signing the firmware should be the final step.

Before the group was chartered, we talked on the list about the possible signature algorithms.  I advocated a hash-based signature because the validation code is small and the validation time is short.  Did this come up?

Russ

> On Feb 27, 2018, at 8:44 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all, 
>  
> For this purpose I created another drawing and also introduced another role, namely the “approver”. (Suggestion for better terminology is welcome.)
>  
> 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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/suit <https://www.ietf.org/mailman/listinfo/suit>

---

From: Dave Thaler <[email-masked]>
Date: Tue, 27 Feb 2018 21:45:59 +0000

In my view, “Signer” is too generic a term for the entity who says it’s appropriate for a specific set of devices on a specific network, since the author is also a “signer”.

“Administrator” is another possible term.  “Approver” is ok, though I find it more confusing than Admin, but maybe that’s just me.

Dave

From: Suit [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Tuesday, February 27, 2018 1:33 PM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [Suit] Approval of Firmware Update

Hannes:

Russ

On Feb 27, 2018, at 8:44 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Ciao
Hannes

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=04%7C01%7Cdthaler%40microsoft.com%7C5d8b52db083a42fa60ea08d57e29a03f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636553639605345842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=y%2F8Lhkn7KMUzDjzy6NzxyCY33jECiOUtcImwcPwvsf4%3D&reserved=0>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 28 Feb 2018 16:49:57 +0000

Hi Michael,

I believe the consensus so far was that we want to offer the possibility for one or more than one signature. I personally believe that the single signature case will be very common in practice (even if the approval process is more complex).

Ciao
Hannes

-----Original Message-----
From: Michael Richardson [mailto:[email-masked]]
Sent: 27 February 2018 19:38
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Suit] Approval of Firmware Update

Good.

    > role, namely the “approver”. (Suggestion for better terminology is

In my mind, the should really only be the approver, and there should probably only be one signature that the end device looks for.

I think that all the complex situations we want (author signs firmware, reviewer signs it, plant operation signs it, operator signs it for odd-numbered devices...) should really about how the device goes from the built-in trust anchors to the authoritative entity.  It could be that we can use SAML or SPKI or ??? for this.

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 28 Feb 2018 16:57:45 +0000

Hi Russ,

Ø  Why not signer?  The quality control / release process will be different in many situations, but signing the firmware should be the final step.

Currently the definition of the author says:

   -  Author: The author is the entity that creates the firmware image,
      signs and/or encrypts it and attaches a manifest to it.  The
      author is most likely a developer using a set of tools.

In that sense he is also a signer. Of course, we can change the author to developer and just define it as

   -  Developer: The developer is the entity that creates the firmware image.

And then we would have to add the signer:

   -  Signer: The signer is the entity that approves the distribution of the
      firmware and signs the manifest and optionally encrypts the firmware.
      There may be multiple signers involved in the distribution or multiple
      approval steps involving only a single signature computation.

While it does not properly address the multi-stage approval process nicely I think it is better than the earlier version.

What do you think?

Ø  Before the group was chartered, we talked on the list about the possible signature algorithms.  I advocated a hash-based signature because the validation code is small and the validation time is short.  Did this come up?

This topic did not come up in the conference call on Monday but I had the impression from earlier discussions that this is a direction we should explore particularly since the larger signature size will in this application be less of a problem given the size of the firmware image in relationship to it. IMHO this could even be a Hackathon project.

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Wed, 28 Feb 2018 17:39:31 -0500

Hannes Tschofenig <[email-masked]> wrote:
    > I believe the consensus so far was that we want to offer the
    > possibility for one or more than one signature. I personally believe
    > that the single signature case will be very common in practice (even if
    > the approval process is more complex).

I actually insist that our format support more than one signature!
So we are in violent agreement there.
It's critical for an audit trail and the like that the format support
multiple signatures.  And the Cose Signature construct does exactly that.
(As does CMS)

However, what I'm suggesting is that rather than have the end-device evaluate
some (possibly complex) series of assertions supported by multiple
signatures, that instead it could outsource that to the Approver, the result
being an additional signature from the "Approver"

Now, instead of trying to determine how all the various (signed) statements
go together, the problem is reduced to determining if this is the right Approver.
That problem is really no more difficult than classic Certificate Authority
(or AA) processing.  Or it can be done with an artifact like the voucher
that ANIMA has just created.

    > -----Original Message----- From: Michael Richardson
    > [mailto:[email-masked]] Sent: 27 February 2018 19:38 To: Hannes
    > Tschofenig Cc: [email-masked] Subject: Re: [Suit] Approval of Firmware
    > Update

    > odd-numbered devices...) should really about how the device goes from
    > the built-in trust anchors to the authoritative entity.  It could be
    > that we can use SAML or SPKI or ??? for this.

    > 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.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 1 Mar 2018 08:54:03 +0400

"Signers" don't sign firmware, they sign a claim of fitness for a specific purpose/usage situation. The author may have no idea what that purpose is. 

Sent from mobile

> On 28. Feb 2018, at 20:57, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Russ,
>  
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 1 Mar 2018 07:48:26 +0000

Hi Carsten,

In an IoT context I would argue that an author often has a fairly good idea where his code will be used since IoT devices are often purpose built.
Strictly speaking you are right that the signature isn’t really over the firmware itself but rather over the manifest, which includes the hash of the firmware. So, there has to be a relationship between the signature covering the manifest including the claims and the firmware it relates to.

I do, however, agree that the terminology I proposed below is not ideal. I am open to other suggestions.

Ciao
Hannes

From: Carsten Bormann [mailto:[email-masked]]
Sent: 01 March 2018 05:54
To: Hannes Tschofenig
Cc: Russ Housley; [email-masked]
Subject: Re: [Suit] Approval of Firmware Update

On 28. Feb 2018, at 20:57, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi Russ,

What do you think?

Ciao
Hannes