Re: [SCITT] Intel is taking the lead on a Trust Service Registry

[John Andersen <[e-mail]>]

Hi Hannes,

Yes. This use case is a specialization of (cross between) the following use
cases from the Detailed Software Supply Chain Uses Cases for SCITT
<https://datatracker.ietf.org/doc/draft-ietf-scitt-software-use-cases/> doc.

   - 3.3: Security Analysis of a Software Product
      - We'll cover OpenSSF Scorecard and other analysis mechanisms
      including meta static analysis / aggregation (example: GUAC).
   - 3.4: Promotion of a Software Component by multiple entities
      - We'll cover how these entities can leverage analysis mechanisms to
      achieve feature and bugfix equilibrium across the diverged environment.
         - Future use cases could explore semantic patching to patch across
         functionally similar projects.

Thank you,
John


On Tue, Jul 18, 2023 at 02:11 Tschofenig, Hannes <
[e-mail]> wrote:

> Hi John,
>
>
>
> do you think your use case is covered in the list of use cases from
> draft-ietf-scitt-software-use-cases-00:
>
>
>
> •             3.1.  Verification that Signing Certificate is Authorized by
> Supplier
>
> •             3.2.  Multi Stakeholder Evaluation of a Released Software
> Product
>
> •             3.3.  Security Analysis of a Software Product
>
> •             3.4.  Promotion of a Software Component by multiple entities
>
> •             3.5.  Post-Boot Firmware Provenance
>
> •             3.6.  Auditing of Software Product
>
> •             3.7.  Authentic Software Components in Air-Gapped
> Infrastructure
>
> •             3.8.  Firmware Delivery to large set of constrained IoT
> Devices
>
> •             3.9.  Software Integrator assembling a software product for
> a smart car
>
>
>
> If it is not covered in this list, what text would need to be added?
>
>
>
> Ciao
> Hannes
>
>
>
>
>
> *Von:* SCITT <[e-mail]> *Im Auftrag von *John Andersen
>
>
> *Gesendet:* Samstag, 15. Juli 2023 18:33
> *An:* [e-mail]
> *Cc:* Hannes Tschofenig <[e-mail]>; [e-mail]
> *Betreff:* Re: [SCITT] Intel is taking the lead on a Trust Service
> Registry
>
>
>
> Thanks guys,
>
>
>
> We’re trying to outline a methodology for securing a rolling release
> across a poly repo development topology. Amber is a piece which can fit
> into that methodology. S2C2F recommends rebuilding OSS and mirroring. When
> pulling directly from upstream without org specific patches, this results
> in duplication of builds across the industry, lots of wasted compute. By
> leveraging artifact upload admission control policy engines running in
> attested environments we can enable trusted cross org data sharing. As
> build systems build software and store the content addresses of the BOMs
> and associated metadata in transparency services, they enable downstream
> users to verify when third parties are running that specific software
> within attestation enabled environments.
>
>
>
> Just as builds of OSS are attested, we can attest to the trust we have in
> that OSS via the same mechanisms, by running projects like OpenSSF
> scorecard within the same style of environment we use to build packages.
>
>
>
> Federation of built package and trust attestations via transparency
> services enables peer to peer (or org to org) communication of what we
> expect software to be when built (SLSA) and if we think one should use the
> software (Scorecard). This also forms the basis for a sort of review system.
>
>
>
> I know this is fairly abstract, but once again, from the definition of the
> reference entity perspective we can about the methodology for trusting
> components. Confidential compute and attestations from image builds within
> those environments are one way we can facilitate decentralization of
> communication of data related to trustworthiness. This is because we
> potentially (future looking) can tie attestations back to arbitrary
> hardware roots of trust. Obviously that’s not the current setup, but
> independent verification leveraging end user defined sets of hardware
> rooted public keys could potentially facilitate true decentralized
> communication in a trustworthy manner. That's the hope at least, please
> shoot holes in that until it’s solid or falls over.
>
>
>
> Thank you,
>
> John
>
>
>
> On Thu, Jul 13, 2023 at 05:59 Dick Brooks <
> [e-mail]> wrote:
>
> John,
>
>
>
> Here’s the link to the Project Amber story that Hannes is referring to:
>
>
> https://www.intel.com/content/www/us/en/newsroom/news/trust-service-startup-inside-chip-company.html
>
>
>
> Thanks,
>
>
>
> Dick Brooks
>
>
>
> *Active Member of the CISA Critical Manufacturing Sector, *
>
> *Sector Coordinating Council – A Public-Private Partnership*
>
>
>
> *Never trust software, always verify and report!
> <https://reliableenergyanalytics.com/products>* ™
>
> http://www.reliableenergyanalytics.com
>
> Email: [e-mail]
>
> Tel: [phone]
>
>
>
>
>
> *From:* Hannes Tschofenig <[e-mail]>
> *Sent:* Thursday, July 13, 2023 8:29 AM
> *To:* 'John Andersen' <[e-mail]>;
> [e-mail]
> *Cc:* [e-mail]
> *Subject:* AW: [SCITT] Intel is taking the lead on a Trust Service
> Registry
>
>
>
> Thanks for pointing us to your work, John.
>
>
>
> Project Amber, as pointed out by Dick, is an attestation verification
> service (the verifier in the IETF RATS terminology). Intel has ben
> operating such a service in the past for prior Intel attestation
> technologies.
>
>
>
> How is your project on “Rolling Alice” related to Project Amber?
>
>
>
> Ciao
>
> Hannes
>
>
>
> *Von:* SCITT <[e-mail]> *Im Auftrag von *John Andersen
> *Gesendet:* Samstag, 27. Mai 2023 20:36
> *An:* [e-mail]
> *Cc:* John Whiteman <[e-mail]>; [e-mail];
> [e-mail]; scrm-nist <[e-mail]>; swsupplychain-eo <
> [e-mail]>
> *Betreff:* Re: [SCITT] Intel is taking the lead on a Trust Service
> Registry
>
>
>
> This talk is the foundation for this work:
>
>
> https://gist.github.com/07b8c7b4a9e05579921aa3cc8aed4866#file-rolling_alice_progress_report_0003_down_the_dependency_rabbit_hole_bsides_portland_2019-md
>
>
>
> Progress is slow but steady. The goal is to bake as much of the
> methology’s risk analysis and reaction capabilities into existing tooling,
> processes, formats, and infrastructure as possible.
>
>
>
> Thank you,
>
> John
>
>
>
> On Sat, May 27, 2023 at 11:19 John Andersen <[e-mail]>
> wrote:
>
> I wholeheartedly agree with you!!!
>
>
>
> Hence the pursuit of Alice Intelligence (AI, John W gets credit for that
> acronym)
>
> https://mailarchive.ietf.org/arch/msg/scitt/iEAhuuicVxgoXJiAZIGmpZOctcc/
>
>
>
> Thank you,
>
> John
>
>
>
> On Sat, May 27, 2023 at 10:49 Dick Brooks <
> [e-mail]> wrote:
>
> Thanks, John.
>
>
>
> I’m doubtful that open source, volunteer, software maintainers will want
> to invest their energies doing the tedious work of analyzing software
> supply chain risk assessment data and preserve tamper-proof evidence that
> can be presented in a lawsuit or audit, and support/operate an online,
> reliable service to answer consumer queries like “Is this software product
> vulnerable as of right now?”. It’s a lot of tedious work, that must be done
> in order to operate a credible, legitimate “Trust Registry” Service, that
> also costs money to operate.
>
>
>
> But I’ve been wrong before, I never thought anyone would buy a “pet rock”
> but some did.
>
> https://en.wikipedia.org/wiki/Pet_Rock
>
>
>
> Thanks,
>
>
>
> Dick Brooks
>
>
>
> *Active Member of the CISA Critical Manufacturing Sector, *
>
> *Sector Coordinating Council – A Public-Private Partnership*
>
>
>
> *Never trust software, always verify and report!
> <https://reliableenergyanalytics.com/products>* ™
>
> http://www.reliableenergyanalytics.com
>
> Email: [e-mail]
>
> Tel: [phone]
>
>
>
>
>
> *From:* John Andersen <[e-mail]>
> *Sent:* Saturday, May 27, 2023 1:32 PM
> *To:* John Whiteman <[e-mail]>;
> [e-mail]
> *Cc:* [e-mail]; [e-mail]; scrm-nist <[e-mail]>;
> swsupplychain-eo <[e-mail]>
> *Subject:* Re: [SCITT] Intel is taking the lead on a Trust Service
> Registry
>
>
>
> Hi Dick,
>
>
>
> Thanks for sending those and looping them into this discussion. Sections
> 2.1.1 and 3.2 respectively look related to the high level goals of the use
> case doc. We plan to leverage threat models heavily (
> https://m.youtube.com/watch?v=TMlC_iAK3Rg) to assist with risk
> determination and further sharing of vuln details including how much data
> to share about the architecture of the system context in question for the
> triggering event.
>
>
>
> We want to enable OSS maintainers, and the secure software forges to have
> these same capabilities.
>
>
>
> Thank you,
>
> John
>
>
>
> On Sat, May 27, 2023 at 10:09 Dick Brooks <
> [e-mail]> wrote:
>
> Thanks, John.
>
>
>
> I’m not familiar with the vuln sharing goals of OpenSSF stream 8, but I am
> familiar with the NIST Vulnerability Disclosure concepts in SP 800-216 and
> C-SCRM SP 800-161:
>
> https://csrc.nist.gov/publications/detail/sp/800-216/final
>
>
>
> This document recommends *guidance for establishing a federal
> vulnerability disclosure framework, properly handling vulnerability
> reports, and communicating the mitigation and/or remediation of
> vulnerabilities.* The framework allows for local resolution support while
> providing federal oversight and should be applied to all software,
> hardware, and digital services under federal control.
>
>
>
> The SP 800-216 framework is also in harmony with SP 800-161 RA-5
> Vulnerability Disclosure Reports, where software suppliers provide
> consumers with software product vulnerability disclosures, at the SBOM
> component level:
>
> https://csrc.nist.gov/publications/detail/sp/800-161/rev-1/final
>
>
>
>
>
> Thanks,
>
>
>
> Dick Brooks
>
>
>
> *Active Member of the CISA Critical Manufacturing Sector, *
>
> *Sector Coordinating Council – A Public-Private Partnership*
>
>
>
> *Never trust software, always verify and report!
> <https://reliableenergyanalytics.com/products>* ™
>
> http://www.reliableenergyanalytics.com
>
> Email: [e-mail]
>
> Tel: [phone]
>
>
>
>
>
> *From:* John Andersen <[e-mail]>
> *Sent:* Saturday, May 27, 2023 12:58 PM
> *To:* [e-mail]
> *Cc:* [e-mail]; [e-mail]; scrm-nist <[e-mail]>;
> swsupplychain-eo <[e-mail]>
> *Subject:* Re: [SCITT] Intel is taking the lead on a Trust Service
> Registry
>
>
>
> WIP but related:
>
> https://github.com/ietf-scitt/use-cases/pull/18
>
>
>
> Have been mocking up how we can run SCITT within TEEs which leverage the
> Amber attestation environment to attest to validity of insert policy run (
> https://github.com/scitt-community/scitt-api-emulator/pull/27#issuecomment-1528073552
> ) within hermetic builds. This facilitates a recursive trust relationship
> which enables dependency review (trust propagation) of OSS. Results are
> federated across the decentralized network of software forges.
>
>
>
> This work is in pursuit of the vuln sharing goals of OpenSSF stream 8.
>
>
>
> Thank you,
>
> John
>
>
>
> On Sat, May 27, 2023 at 08:11 Dick Brooks <
> [e-mail]> wrote:
>
> Hello Everyone,
>
>
>
> This announcement from Intel is further proof that a “Trust Service” is
> becoming a foundational requirement for trustworthy computing.
>
> *A Trust Service Startup Inside the Chip Company*
>
>
> https://www.intel.com/content/www/us/en/newsroom/news/trust-service-startup-inside-chip-company.html
>
>
>
> Amen to this: ““Attestation is the ability for you to prove that something
> is what it says it is,” Yeluri explains. “And that is really the ground
> truth in confidential computing. *If you can’t attest and say it is truly
> what it is, confidential computing is immaterial.”*
>
>
>
> “Before taking that big step, Yeluri and team *checked with a couple
> dozen customers — banks, manufacturers, telecommunications services — and
> received votes of support*.”
>
>
>
> The following observation is “spot on” *based on REA’s experience
> operating the SAG Community Trust Registry ™ (SAG-CTR ™)*:
>
>
>
> “A few suggested Intel just build it as open source. But Yeluri and team
> believed that while the core attestation primitives can be open sourced, *a
> solution could only succeed “as a turnkey service. That means somebody has
> to operate it at scale,” he says, “and we think we can do that.”*
>
>
>
> REA agrees with the above statement, operating a reliable, trustworthy
> “trust service” at scale, like REA’s SAG-CTR, is a lot of work that
> requires the analysis, storage and maintenance of evidence that is
> trustworthy and can be presented during a lawsuit or audit, that cannot be
> properly operated by open source volunteers.
>
>
>
>
> https://www.einpresswire.com/article/545051889/announcing-the-sag-ctr-tm-community-trust-registry-for-digitally-signed-software
>
>
>
> Thanks,
>
>
>
> Dick Brooks
>
>
>
> *Active Member of the CISA Critical Manufacturing Sector, *
>
> *Sector Coordinating Council – A Public-Private Partnership*
>
>
>
> *Never trust software, always verify and report!
> <https://reliableenergyanalytics.com/products>* ™
>
> http://www.reliableenergyanalytics.com
>
> Email: [e-mail]
>
> Tel: [phone]
>
>
>
>
>
> --
> SCITT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scitt
>
>