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

[Hannes Tschofenig <[e-mail]>]

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] <mailto:[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] <mailto:[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

 

 <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: John Andersen <[e-mail] <mailto:[e-mail]> > 
Sent: Saturday, May 27, 2023 1:32 PM
To: John Whiteman <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; scrm-nist <[e-mail] <mailto:[e-mail]> >; swsupplychain-eo <[e-mail] <mailto:[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] <mailto:[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

 

 <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: John Andersen <[e-mail] <mailto:[e-mail]> > 
Sent: Saturday, May 27, 2023 12:58 PM
To: [e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; scrm-nist <[e-mail] <mailto:[e-mail]> >; swsupplychain-eo <[e-mail] <mailto:[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] <mailto:[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

 

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

 

 

-- 
SCITT mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/scitt