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

[John Andersen <[e-mail]>]

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
>
>