User-Agent: Microsoft-MacOutlook/10.e.1.180613
Date: Thu, 21 Jun 2018 05:58:59 -0600
From: David Brown <david.brown@linaro.org>
To: Tamas Ban <Tamas.Ban@arm.com>,
	suit <suit@ietf.org>
CC: "dev-mcuboot@lists.runtime.co" <dev-mcuboot@lists.runtime.co>
Message-ID: <10617C16-B988-42D2-AFB3-BCAC52AABB15@linaro.org>
Thread-Topic: [dev-mcuboot] Reference implementation of SUIT manifest parsing
References: <20180619214859.GA4341@davidb.org>
 <AM6PR08MB312603F07009683980046297E2770@AM6PR08MB3126.eurprd08.prod.outlook.com>
In-Reply-To: <AM6PR08MB312603F07009683980046297E2770@AM6PR08MB3126.eurprd08.prod.outlook.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/FmzkhuDxF9jNFYcFca1N8H3VVdg>
Subject: Re: [Suit] [dev-mcuboot] Reference implementation of SUIT manifest
 parsing
Precedence: list

I don't really have an idea on the code size change.

However, I don't think we should use an existing library for the parsing, b=
ut write custom processing code for the things we support, similar to how we=
 process the TLV data and the signatures now.  It will be best to not just a=
llow any arbitrary signature type, but specifically require certain specific=
 signature types.

David

=EF=BB=BFOn 6/20/18, 9:05 AM, "Tamas Ban" <Tamas.Ban@arm.com> wrote:

    Hi David,
   =20
    Do you have any rough estimate how much will be the code size increased=
 due to the libs for the parsing manifest files in CBOR/COSE format?
   =20
    Does it need a separate lib for parsing CBOR(i.e: tinycbor, cn-cbor) an=
d a different one to verify COSE signing?
   =20
    Tamas
   =20
    -----Original Message-----
    From: dev-mcuboot <dev-mcuboot-bounces@lists.runtime.co> On Behalf Of D=
avid Brown
    Sent: 19 June 2018 23:49
    To: suit <suit@ietf.org>
    Cc: dev-mcuboot@lists.runtime.co
    Subject: [dev-mcuboot] Reference implementation of SUIT manifest parsin=
g
   =20
    At the last hackathon, work was done on implementations of the SUIT man=
ifest format.  One way to describe this kind of work would be as a reference=
 implementation: something that could be a starting point for anyone wishing=
 to use SUIT to develop something.
   =20
    However, I had to limit my involvement in this effort, because some of =
the code being used was covered under the LGPL 2.0.
   =20
    I'm wondering if it would be useful to develop equivalents of this code=
 under a license that would be usable by a larger audience.  I'm actually ha=
ving a pretty hard time understanding how there is any audience for bootload=
er code covered under the LGPL.
   =20
    A few of the reasons that the LGPL doesn't work for me (and I believe d=
oesn't work for many of the current uses).
   =20
      - The FSF considers the Apache 2.0 license to be incompatible with
        the GPLv2 (including the LGPL).
   =20
      - The Apache Software Foundation considers GPLv3 to be compatible in
        only one direction (Apache 2.0 code can be linked into an
        otherwise GPLv3 application, but GPLv3 code cannot be brought into
        an Apache 2.0 project).
   =20
      - The Apache Software Foundation considers the GPLv2 (including
        LGPL) to be incompatible with the Apache 2.0 license.
   =20
      - By Mynewt and Zephyr are licensed under the Apache 2.0 license.
        Mynewt is an Apache project and would fall under their constraints
        of forbidding the including of any code under a GPL license.  The
        Zephyr project requires included code to be under the Apache 2.0
        license, and occasionally will allow other more liberal licensed
        code to be included.
   =20
    Regardless of the above, I see a conflict between the LGPLv2 requiremen=
t that the user be able to modify the LGPLv2 licensed code, and the general =
purpose of SUIT to enforce that only authorized images run on the device.  O=
ne of the purposes of a signed manifest is to restrict the very action that =
the LGPLv2 requires.
   =20
    My conclusions:
   =20
      - libcose (and any other LGPLv2 code) cannot be used by Zephyr,
        Mynewt, due to policies by these projects.  At best, it would end
        up being something that end users would have to incorporate, and
        SUIT support would not be able to become standard support on these
        platforms.
   =20
      - libcose (and any other LGPLv2 code) cannot be used by Zephyr,
        Mynewt, mbed OS, and MCUboot, due to incompatibility between the
        LGPLv2 and the Apache 2.0 license.  (Specifically, I do not
        believe the current mbed OS SUIT work is allowed).
   =20
      - Very few of our end users would want to meet the LGPLv2
        requirement allowing end users to replace the firmware.
        Specifically, those users desiring signed manifests to ensure only
        authorized images can be run are likely intending to prohibit end
        users from running their own versions of the code.
   =20
    I've tried to avoid even looking at the libcose code (and making sure t=
o look at licenses carefully) since it seems likely that I, or someone worki=
ng on Zephyr or MCUboot) will need to implement COSE support in order to sup=
port SUIT.
   =20
    David
   =20
    _______________________________________________
    MCUBoot: a secure, open source bootloader for 32-bit MCUs http://lists.=
runtime.co/mailman/listinfo/dev-mcuboot_lists.runtime.co
    IMPORTANT NOTICE: The contents of this email and any attachments are co=
nfidential and may also be privileged. If you are not the intended recipient=
, please notify the sender immediately and do not disclose the contents to a=
ny other person, use it for any purpose, or store or copy the information in=
 any medium. Thank you.
   =20