Re: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

[Michael Richardson <[e-mail]>]

Phillip Hallam-Baker <[e-mail]> wrote:
    > I see multiple concerns:

    > 1) Every software distribution MUST be signed without exception

    > 2) All software executables and data installed on a machine MUST be
    > signed by the provider.

    > 3) All signatures MUST be under keys that have a trustworthy
    > credential.

    > The reason I reject (3) is because I insist on (1) and (2). I want

I'm with you here, and I agree with your compromise situation.

    > For critical infrastructure devices, I suggest the following:
    > 0) Must identify such machines and label them prominently
    > 1) Software must be signed under trustworthy credential
    > 2) Platform must verify signature before executable is launched.

So you make a distinction between software executables installed on a machine
(above), and "launched" here.   I wanted to be sure that this distinction was
intended.

We have in the past discussed the question of who controls the trust anchor
authorized to perform software updates in a given system.   
That's to be distinguished from who signs the software!

One of the limitations in the Android ecosystem is that one has only two
choices:  trust Google, allow unsigned executables (APKs).   An intermediate choice
could be, "trust anchor FOO".  Trusting more than one gets us into the WebPKI
problem of who is authorized for what, and cert transparency, etc.
Apple does slightly better in that (I understand) Apple insists that all
packages be signed, but allows for some people (developers) to designate
certain phones are allowed to trust the local enterprise.  This doesn't scale
to the general public though.

In the industrial IoT space, I think that operators will want to be the
ultimate authority as to what code runs where.  So the authorized trust
anchor in the device will not be the manufacturer, but the operator.
The operator will verify the signature(s) from the manufacturer of the
software, and then will countersign or resign the MANIFEST with their key.

How this will play out in other spaces, I don't know exactly.
I expect *Tesla* to sign the code in the brake MCU, not Bosch, even though
Bosch made it.  That doesn't mean that Bosch didn't sign the code when it was
transfered to them.  Unfortunately, I don't think the car owner will get to
decide.  How that will play out when the manufacturer declares EOL, I don't
know.  (I have a 30yr old VW.  But, it's a toy, not transport. I use bike +
transit in town)

There will be some equipment which, when the manufacturer says EOL, then the
device needs to die.  There will be other things where this is less important.

What can the IETF do?  Well, I think that we (SUIT WG) needs to consider how
to manage and update authorizations for trust anchors in a standardized way.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [