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

Maybe this an operational, marketplace, policy and certification issue that is often use-case specific?

Apple decided that everything on an iPhone is signed and manages the ecosystem

Google did the same, but a little different.

Certification of FIDO authenticators at higher levels requires SW be under control of the authenticator vendor with signing being a good way to do it.

Maybe GlobalPlatform should run an TEEP certification program that requires signing.

Individual industries, like automotive, industrial infrastructure and such can come up with their operation requirements and/or certification programs.

Maybe Linus can say how signing should work on Linux and get enough momentum to make it happen.

It seems hard for an organization like IETF to know the details of all the use cases and to have enough leverage to make this happen. It doesn’t seem that effective to try to put policy into security considerations.

LL

> On Jun 11, 2021, at 11:39 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> 
> 
> 
> On Fri, Jun 11, 2021 at 2:34 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com>> 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.
> 
> _______________________________________________
> Suit mailing list
> Suit@ietf.org <mailto:Suit@ietf.org>
> https://www.ietf.org/mailman/listinfo/suit <https://www.ietf.org/mailman/listinfo/suit>