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

[Dick Brooks <[e-mail]>]

There are two distinctly different use cases (schemes) where digital signatures are used today in the Energy industry:

 

1.	Peer-Peer trust using PGP keys and private exchange/verification (Natural Gas)
2.	CA issued X.509 certificates, where no a-priori trust relationship exists and a trusted 3rd party provides the trust needed to link the identity tied with the key pair via a certificate

 

Both approaches work well to satisfy the trustworthiness “bar” needed to conduct a business transaction.

 

Phillip, I agree: All software MUST be signed, by a trustworthy party that has been authorized to sign software on behalf of the authorized software supplier/licensor, which a software customer can verify as part of digital signature verification. 

 

This can work under both schemes, IF:

*	The signing credentials can be trusted, meaning the customer has a way to verify trust using scheme 1 or 2
*	The signature on software can be trusted, meaning the customer has a method to verify that the signature uses a trusted credential, and now for the hard part, the customer can verify that the signing party has been authorized by a software supplier to sign code on their behalf, under schemes 1 and 2. This can happen with scheme 1, but I don’t see how this can happen with scheme 2 without supporting infrastructure, that doesn’t seem to exist today. 

 

Thanks,

 

Dick Brooks



 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

 <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com

Email:  <mailto:[e-mail]> [e-mail]

Tel: [phone]

 

From: Phillip Hallam-Baker <[e-mail]> 
Sent: Friday, June 11, 2021 8:18 PM
To: Toerless Eckert <[e-mail]>
Cc: Hannes Tschofenig <[e-mail]>om>; suit <[e-mail]>rg>; Russ Housley <[e-mail]>om>; [e-mail]; Brendan Moran <[e-mail]>
Subject: 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

 

When writing a specification, it is always important to decide on what problems you intend to solve and which you plan to leave for others.

 

Unauthenticated signatures have real proven value in anti-Virus protection. As Marcus Rannum argued over a decade ago, looking for badness is a failing strategy because the badness is infinite. If every copy of Adobe software is signed with a software key that chains to a self signed cert created by adobe, that provides a vast amount of leverage for AV systems even without TTP validation.

 

That is not a theoretical approach, it is precisely how Comodo Default Deny Protection (TM) works. If you build databases of signatures of known good software, spotting the bad or the corrupted software is much easier. 

 

That is why I want all software signed without exception. If you try to gate software signing on a CA issued key you are making exactly the same mistake that keeps S/MIME at 0.00001% of email traffic. As I argued in the SSL cert space since 2000 or so, Web browsers should accept self-signed certificates without complaint or notification to the user. Just drop the padlock icon telling them the site is secure. 

 

I don't think that the answer to the problem of validation is to set up a mickey mouse CA that provides certificates without any validation of organization existence, accountability, proof of right, etc. giving out rubbish certs for free. Gresham's law applied to the WebPKI: the bad certs drive out the good. If you try to make CA issued certs mandatory, someone will come along and reduce the issue criteria to the point where they have no value over self-signed.

 

 

Yes, I am proposing a callsign registry that could be adapted to code signing. But to be honest, that is not one of the primary motivations for it nor is it something I have given a lot of thought to in the design of callsign.

 

My rough notion is this: @alice, @bob, @carol work for @threshold As they are developing code, every build they create is signed under their personal software developer key bound to their Mesh profile by means of a connection assertion and thus their callsign. So Alice isn't going to run any developer build not signed by any of the three of them.

 

When it comes to the general public trusting the signature, they are not going to know Alice or Bob or Carol and they probably don't know Threshold so the call sign alone really isn't enough to convince J. Random User to install and run it. So @Threshold gets a TTP validation of their key and that is maybe gated so that two out of the three of them have to sign. 

 

 

 

On Fri, Jun 11, 2021 at 7:19 PM Toerless Eckert <[e-mail] <mailto:[e-mail]> > wrote:

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] <mailto:[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] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/suit


-- 
---
[e-mail] <mailto:[e-mail]>