Re: [Suit] WG: WGLC on draft-ietf-suit-firmware-encryption-14 due on September 11, 2023

[Michael Richardson <[e-mail]>]

Hannes Tschofenig <[e-mail]> wrote:
    >> 3. "The author treats the distribution system as the initial recipient"
    >> this is also not-standardized, and I think might involve some kind of
    >> integration with a sales channel.

    > This is not standardized, as far as I know. However, this is the area of
    > classical Web APIs.

My point in listing it as out-of-scope being that it requires a decision for
someone trying to produce a complete solution.  This is also a place where
other bodies (OPC, Thread, MATTER, ...) could well have a profiling role to play.

    >> } the distribution system needs to know about
    >> } the properties of the deployed devices
    >>
    >> how does this distribution system know this? Is it derivable from the content
    >> that the author/sender provides, or does it require configuration?

    > If the distribution system, which is more than a file server, encrypts
    > the payload it needs to know what content key distribution method the
    > device supports based on the keys it maintains for the devices.

Yes, but how does it know what key distribution methods the device supports?
Assume that we have a distribution system that is installed and maintained by
the OwnerOperator of the network.  For instance a campus or enterprise
network, or a *building* automation network.  The intent is for this
distribution system to provide firmware update services for a variety of
device types (maybe several dozen different types) from a variety of
manufacturers.

    >> I suggest that the different ways of using AES-KW, with common KEK across
    >> devices, vs per-device KEK be clearly named and listed a different options.
    >> And then third option of different CEKs!

    > Let me think about given the versions different names.

1. Per-device-type symmetric key. (PDTSK?)
2. Per-device symmetric key, singly-encrypted firmware. (PDSKS)
3. Per-device symmetric key, unique-encrypted firmware  (PDSKU)
4. Per-device ES, singly encrypted firmware. (PDESS)
5. Per-device ES, unique-encrypted firmware. (PDESU)

{PDTSK makes me think Saskatoon. Also Pacific Daylight Time.
But, I'm known for my whimsical naming.}

    >> Is there a case where all devices have the same g^y?

    > No, not in this document. Should there be?

I'd rather that there was not!   Some people might think it simpler.
That would be:
6. Per-device-type ES. Singly Encrypted firmware.

    >> Ditto comment about PIC becoming more and more common, and anyway, compile to
    >> two different slots.

    > Where is PIC becoming more popular? Which RTOS supports PIC?

My impression is that it is often default for RIOS-OS, and/or RISC-V.
My impression is that the problem has usually been compiler support.

    >> I think this section 7 could be an appendix.
    >> sections 7.1/7.2 seems more of a standard statement, and contains BCP14
    >> language.

    > What would be the benefit of moving the text to the appendix?

Not everyone needs to know, and it seems that it buries section 7.1/7.2.

    >> Thanks for including examples with private keys. I think you can mark those
    >> pieces as code blocks so they are more easily extracted.

> What would be the best way of doing it here?

In kramdown, you would use ~~~~ xxxx I think.
In xml2rfc, CODE BEGINS filename.


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide