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

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Jun 11, 2021 at 2:34 AM Hannes Tschofenig <[e-mail]>
wrote:

> Hi Phil,
>
>
>
> a few clarifying questions.
>
>
>
>    - What is a “trustworthy credential” for you?
>    - Who is the “provider” here?
>    - What do you mean by “Must identify such machines”? Are you saying
>    that the software / firmware update must identity the machine it applies to?
>    - When you say “Every software distribution MUST be signed without
>    exception” are you trying to distinguish between the signing the software
>    vs. securing the distribution? With regards to the exception you are not
>    talking about what happens during manufacturing.
>
>
I am distinguishing between Sign ( Zip (files) , k) and Sign (files, k).

Authenticode only signed the software distribution package, most of what
has followed has done the same. That is a useful control of course because
an installer is an executable that runs on the machine. But it is necessary
but not sufficient: Every executable, every piece of installed data should
be signed without exception.

On the other issues, well it totally depends on your application and your
regulator. In the aftermath of Diginotar we had a lot of discussions of
what should be subject to audit. My position was that is actually something
the CA decides. Basically, the CA can define their boundary to be anywhere
they like, that is purely a matter for them to decide.

The catch here is that if you are going to show that your practices meet
your policy, then you have to show that all your cert issuing machinery is
subject to audit. Contrawise, the more of your machinery you stick within
the audit boundary, the harder time you are going to have showing it is
secure.

I would apply the same approach here. The pipeline provider etc. has to
show that its operations are secure. I am not going to write a list of what
they have to pur inside or outside of their security perimeter, I am merely
saying that they have to define one, they have to show that all the
necessary operations are inside it and that everything inside it is
sufficiently secure.

If we are talking about a pipeline then CABForum EV certs are probably
sufficient. For civil nuclear, I would consider that a starting point, I
would want all software to be signed under a cert that was individually
enumerated and credentialed.

It is worth pointing out that the reason colonial pipeline was affected so
badly was probably that they were sending multiple types of fuel down the
same pipe in batches. That game is only going to work if you can absolutely
guarantee that you aren't going to put the load of tar into a tank full of
top grade aviation fuel. So their problem probably wasn't on their actual
operations side itself, the thing they were looking at. They had not
understood that the database of what fuel is where was actually critical to
operations.


On provider, I am being deliberately vague because sometimes the provider
is going to be the developer, other times it isn't. A large amount of
Ubuntu packages are signed by the people who are putting the packages
together who are not the actual developer. This third party work does have
value in that there is a curation process going on there and it is possible
to imagine mechanisms whereby detected insertion of malware could be
revoked. But we don't have those at this point of course.