Re: [SCITT] Intel is taking the lead on a Trust Service Registry
John Andersen <johnandersenpdx@gmail.com> Sat, 15 July 2023 16:33 UTC
Return-Path: <johnandersenpdx@gmail.com>
X-Original-To: scitt@ietfa.amsl.com
Delivered-To: scitt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A098BC151095 for <scitt@ietfa.amsl.com>; Sat, 15 Jul 2023 09:33:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkmSS8wLRUen for <scitt@ietfa.amsl.com>; Sat, 15 Jul 2023 09:32:59 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922E2C15107A for <scitt@ietf.org>; Sat, 15 Jul 2023 09:32:58 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-4fba8f2197bso4977721e87.3 for <scitt@ietf.org>; Sat, 15 Jul 2023 09:32:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689438776; x=1692030776; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9LgIZCSKGljy3bbPCBQZJMg7wvNsO0proGFT6iwBOqY=; b=RVmeeBndtCOrio1Z9gnZeNRNpr5N9F1cF2Ed+dNKnWBKS1cDubXcuBiY7z8XMPL6Rv GqQF8hIgH4DuymHXdErlfQRw5w+FBWm2E4OQJotfLQGWUow1mOQJyL4bPGKriUgRZPOi /sU7FBjWz9DBsEB6a8m4eHMj1KmJ5hosTPFXZWEv7uHxSJNuX9zBrbegMdWq5xnmvpYh 3BzBLcBMJDh8cMaUy5JgkvH9cbvTTCxtuPV8WdAQwLvokhO9HBIHsv4z3W6Oo83qC+3s 2ytLsUsPDZ6fOv2x3lv75aqY6P999N+SF8DRA+2HBTUKE+rdW4KFYeAgP5r7KbKcV5ps KxYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689438776; x=1692030776; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9LgIZCSKGljy3bbPCBQZJMg7wvNsO0proGFT6iwBOqY=; b=bTYEp5+izRp4c/o2lAiK3PAtIGrw7CqiMX3H7WVo3+bNOIuBXJWlzsl+0RAzJN/Yw3 DivMxSMyAyPvz8QCNIF9/0QE+52YJRN98FWCF2tAaiM7K6p2tGW9UVgNzrEcZDYRYThC vSEVGcL0tQRlXLStN4j9gyxq5j/oE0lbFxRdhZoWU1TupvIuP7vwEde5+2iL467xWceO EYb+EWrJlf6Wv1OBFrRC+OQHyYxPKyshtG9xCgEqzoIzLLHExu+eg1nbrtYamuY1VBZV KH72iA4vimhzdXqPEHWEkbhOmVRZLqiBw2WE93OEMpIge2eHHpEJiHBVSkRNnG/S0B22 js8Q==
X-Gm-Message-State: ABy/qLbDglsOY5V5mfS2AO/CtQy37j07+Hfj91OamYtpI/n30LMKck6z 0oI6bPgRbl3vg7J4hI6ctGADJu7w3myfl6ySsrw=
X-Google-Smtp-Source: APBJJlHEBcg3tLw96mfdvS57bz+3o9s27N2Iq+yXhhaDdorjkpls90hpeeZ4R0ejpcRlJBgBr9GJeHbPL9ZWRNLX1DA=
X-Received: by 2002:a05:6512:1320:b0:4fb:8ff3:1f72 with SMTP id x32-20020a056512132000b004fb8ff31f72mr5696168lfu.1.1689438775723; Sat, 15 Jul 2023 09:32:55 -0700 (PDT)
MIME-Version: 1.0
References: <238d01d990ad$81b699b0$8523cd10$@reliableenergyanalytics.com> <CAPFAYiVeq0Y+4U=yjia6CvpsXEC6HbtunHkj07SMp2X+Mz+ZfA@mail.gmail.com> <242d01d990bd$f8423ed0$e8c6bc70$@reliableenergyanalytics.com> <CAPFAYiVMA+HSFjBbXOd8F9VdRYiMcVPqobc2AyX79zekUz5MTw@mail.gmail.com> <246501d990c3$9d1fa6e0$d75ef4a0$@reliableenergyanalytics.com> <CAPFAYiX+arF6HMBfkGRAU==NJnK-KrSYqefQKh_wjOUVw9eQ0w@mail.gmail.com> <CAPFAYiXbzyL=+3u_8TV8B7icwFJq1DT5wjqGCbNi10Wa7uNNjw@mail.gmail.com> <012001d9b585$9daae200$d900a600$@gmx.net> <01cc01d9b589$cad87270$60895750$@reliableenergyanalytics.com>
In-Reply-To: <01cc01d9b589$cad87270$60895750$@reliableenergyanalytics.com>
From: John Andersen <johnandersenpdx@gmail.com>
Date: Sat, 15 Jul 2023 09:32:43 -0700
Message-ID: <CAPFAYiUAw=gV80rP+1jFSmi6mrsfzgcNL1JLbzBjkQExNw7buQ@mail.gmail.com>
To: dick@reliableenergyanalytics.com
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, scitt@ietf.org
Content-Type: multipart/related; boundary="00000000000018f0dc0600891e57"
Archived-At: <https://mailarchive.ietf.org/arch/msg/scitt/fq_jN9WNXMqd3jPcc_HldIyzgao>
Subject: Re: [SCITT] Intel is taking the lead on a Trust Service Registry
X-BeenThere: scitt@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Supply Chain Integrity, Transparency, and Trust" <scitt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scitt>, <mailto:scitt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scitt/>
List-Post: <mailto:scitt@ietf.org>
List-Help: <mailto:scitt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scitt>, <mailto:scitt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Jul 2023 16:33:03 -0000
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 <dick@reliableenergyanalytics.com> 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: dick@reliableenergyanalytics.com > > Tel: +1 978-696-1788 > > > > > > *From:* Hannes Tschofenig <hannes.tschofenig@gmx.net> > *Sent:* Thursday, July 13, 2023 8:29 AM > *To:* 'John Andersen' <johnandersenpdx@gmail.com>; > dick@reliableenergyanalytics.com > *Cc:* scitt@ietf.org > *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 <scitt-bounces@ietf.org> *Im Auftrag von *John Andersen > *Gesendet:* Samstag, 27. Mai 2023 20:36 > *An:* dick@reliableenergyanalytics.com > *Cc:* John Whiteman <john.whiteman@owasp.org>; ofcio@omb.eop.gov; > scitt@ietf.org; scrm-nist <scrm-nist@nist.gov>; swsupplychain-eo < > swsupplychain-eo@nist.gov> > *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 <johnandersenpdx@gmail.com> > 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 < > dick@reliableenergyanalytics.com> 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: dick@reliableenergyanalytics.com > > Tel: +1 978-696-1788 > > > > > > *From:* John Andersen <johnandersenpdx@gmail.com> > *Sent:* Saturday, May 27, 2023 1:32 PM > *To:* John Whiteman <john.whiteman@owasp.org>; > dick@reliableenergyanalytics.com > *Cc:* ofcio@omb.eop.gov; scitt@ietf.org; scrm-nist <scrm-nist@nist.gov>; > swsupplychain-eo <swsupplychain-eo@nist.gov> > *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 < > dick@reliableenergyanalytics.com> 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: dick@reliableenergyanalytics.com > > Tel: +1 978-696-1788 > > > > > > *From:* John Andersen <johnandersenpdx@gmail.com> > *Sent:* Saturday, May 27, 2023 12:58 PM > *To:* dick@reliableenergyanalytics.com > *Cc:* ofcio@omb.eop.gov; scitt@ietf.org; scrm-nist <scrm-nist@nist.gov>; > swsupplychain-eo <swsupplychain-eo@nist.gov> > *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 < > dick@reliableenergyanalytics.com> 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: dick@reliableenergyanalytics.com > > Tel: +1 978-696-1788 > > > > > > -- > SCITT mailing list > SCITT@ietf.org > https://www.ietf.org/mailman/listinfo/scitt > >
- [SCITT] Intel is taking the lead on a Trust Servi… Dick Brooks
- Re: [SCITT] Intel is taking the lead on a Trust S… John Andersen
- Re: [SCITT] Intel is taking the lead on a Trust S… Dick Brooks
- Re: [SCITT] Intel is taking the lead on a Trust S… John Andersen
- Re: [SCITT] Intel is taking the lead on a Trust S… Dick Brooks
- Re: [SCITT] Intel is taking the lead on a Trust S… John Andersen
- Re: [SCITT] Intel is taking the lead on a Trust S… John Andersen
- Re: [SCITT] Intel is taking the lead on a Trust S… Hannes Tschofenig
- Re: [SCITT] Intel is taking the lead on a Trust S… Dick Brooks
- Re: [SCITT] Intel is taking the lead on a Trust S… John Andersen
- Re: [SCITT] Intel is taking the lead on a Trust S… Dick Brooks
- Re: [SCITT] Intel is taking the lead on a Trust S… Tschofenig, Hannes
- Re: [SCITT] Intel is taking the lead on a Trust S… John Andersen