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

John Andersen <johnandersenpdx@gmail.com> Sat, 27 May 2023 17:31 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 CDE37C151062 for <scitt@ietfa.amsl.com>; Sat, 27 May 2023 10:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_BLOCKED=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 5K35kdZTk2zp for <scitt@ietfa.amsl.com>; Sat, 27 May 2023 10:31:44 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 064FEC151065 for <scitt@ietf.org>; Sat, 27 May 2023 10:31:43 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-3f6a6b9c079so12623655e9.1 for <scitt@ietf.org>; Sat, 27 May 2023 10:31:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685208702; x=1687800702; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2YWEVIVm2GZlsS0mSmpyJsHw0ahCT1Mx0FwqY4Nx/7g=; b=nlu3XgVMgcmJKN3/H3Aj653DpmLGQ46g5ApGIyHQ3l1xjYS9iO9WbaTQnoQ8Ser8T/ 4H2jKyLHpvgbDNyB9jyPTSZnpoDJm4RGLuY6BhBcAohpRlWK7SQdlPOJEnu30IEpQTAD mo85Cok7c2R5BtMkRNCafUAQA/u0SAK2xVce46xYuj3bNuVQ/BLOFyxhhYgBh07Mojqs Hul8bymV81k8zZJv29UHhGALoN+3rKsWLPdIfk68IMrt6m3WqYCRUyli60UJkwKnePWy CGb47ToGy7FT8a3tBMytz6Kvkv8HEChmXd0onomDkxTzuL8EaEwI3tK3dPMnY9eYOkUe SMRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685208702; x=1687800702; 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=2YWEVIVm2GZlsS0mSmpyJsHw0ahCT1Mx0FwqY4Nx/7g=; b=atwSC+BT4TpHeNv3/b85s/e4ID4CR/sXYh5BQR8syy7Ukp2TirBzExEqc2dssLY/kj KpsE8OEbjp2NorsGBvmr+aAN1KFHDgFpir009NjKxkTH2AdocHO7RYuPw3BPVVhQ5saq ESDPne8mkyHWyh32Ysm/UaSZfkKuaTQ5twdn2iF9TV/g92ezYNBHzKloIur3eYeOGKHg vkkVFvZDaq8DK+CFZHWmX0a8xEKHGHVzq9D54jh3f8ULUPCxHhxMek6v0vrR1zSzJZ6W nl4ylgQacHIaSE9ZhCrvKBLsKdE4D532bRltJcU6uYUsKJZrMNmDEaqI0Db30ErzN9Dm AvZQ==
X-Gm-Message-State: AC+VfDwg9De/Iopjm9v0uaeDlaBxSMYxJE1g6XHuWK2inTbBtd+U30wd 164X8kX8aylr6a5B+zgkIja1kZy9CM6C4VcVyC0=
X-Google-Smtp-Source: ACHHUZ7x34srs6apx+US96Is/2fPqu4eejAd7iYVKulSYeriHSDLpgW5h58ZW3zT7dNJG0fvZjwIYTn+JnKKxX858/8=
X-Received: by 2002:a1c:f704:0:b0:3f1:74bd:bc22 with SMTP id v4-20020a1cf704000000b003f174bdbc22mr4335108wmh.6.1685208701572; Sat, 27 May 2023 10:31:41 -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>
In-Reply-To: <242d01d990bd$f8423ed0$e8c6bc70$@reliableenergyanalytics.com>
From: John Andersen <johnandersenpdx@gmail.com>
Date: Sat, 27 May 2023 10:31:30 -0700
Message-ID: <CAPFAYiVMA+HSFjBbXOd8F9VdRYiMcVPqobc2AyX79zekUz5MTw@mail.gmail.com>
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>
Content-Type: multipart/related; boundary="00000000000007b80e05fcb03ad1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/scitt/pnwJ9lCL70O6aJo2ZZbL7dkejnU>
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, 27 May 2023 17:31:48 -0000

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