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

[Toerless Eckert <[e-mail]>]

Phil,

a) Let me see if i get your high level point correctly and/or expand correctly:

   - We want signatures on all pieces of software/data loaded onto systems.
     These signatures allow to authenticate who (signer) says what
     about the signed software/data. Not sure if there is a framework
     for the "what" there is, but i could think of more "what" than
     just an implied "authentic" binary flag implied by the presence of
     the signature.
   - What to make out of those signatures should be different policy decision. 
     As in: just because its signed doesn't mean i trust the software to run
     on my system. Trust policies depend on signatures but would embody
     additional critera such as specific CA for specific software purposes
     or the like.

b)  Wrt to CA policy freedom (" Basically, the CA can define their boundary
    to be anywhere they like, that is purely a matter for them to decide")

    This reminds me a bit of ISO9000 and how uneducated customers are. As in:
    There can be thousands of software companies out there that customers
    trust to be reliable because the software company is ISO9000 certified,
    and none of those customers ever looked up what that means.

    As in "Our software company ISO-9000 process: before we start coding,
    every day, we dance on the tables and drink 3 beers to get into the mood.
    End of ISO-9000 process". The ISO-9000 auditors also got free beers,
    everyone was happy. Worst part: that process might lead to more reliable
    software than some other ISO-9000 audits i have seen.

    Aka: I don't think you get around having some standards for the
    security boundary you describe and whoever defines that boundary/audit
    standard could make nice money from e.g. also getting involved
    into the software signing.

Cheers
    Toerless

On Fri, Jun 11, 2021 at 02:39:11PM -0400, Phillip Hallam-Baker wrote:
> 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.

> _______________________________________________
> Suit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/suit


-- 
---
[e-mail]