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

Dick Brooks <dick@reliableenergyanalytics.com> Sat, 27 May 2023 17:09 UTC

Return-Path: <dick@reliableenergyanalytics.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 582B6C14CEFE for <scitt@ietfa.amsl.com>; Sat, 27 May 2023 10:09:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=reliableenergyanalytics.com header.b="Y6sAhYbf"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="of8Pxuk8"
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 8bMRL7Kcen4p for <scitt@ietfa.amsl.com>; Sat, 27 May 2023 10:09:18 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 56DDCC14CEF9 for <scitt@ietf.org>; Sat, 27 May 2023 10:09:18 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 909745C00F5; Sat, 27 May 2023 13:09:17 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sat, 27 May 2023 13:09:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= reliableenergyanalytics.com; h=cc:cc:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:reply-to:sender:subject :subject:to:to; s=fm2; t=1685207357; x=1685293757; bh=j7FpUM00K7 Z38vMF6hRGIqeTfMQAoGL+JYlszghlNlE=; b=Y6sAhYbfpYhizNpjEZQ/n44dAl Cv+xmNnpzqQHZih4t/Rkz9Xn7x/YZ7DIIoYSGfFlVBWAzfSUKMH5NUbnl4SJtEC5 4cwD137kTF41D+YEnzCtSGHBC5YtcCjFZSsZfSi8jW1/d27dhiG+WUj5g94riPzW jXPp6p/5dtLhEOjaOY1A4qzz/lMZoZ8Z7FZ5XP0h52cIDPEcdw/aF61XQjpbA/ji S2t+O/NPCyP0JqTatr5fgJt/Dww7jbTMOj1HkX8uaTWXfcLcBaIiVxTyArj4PKjt qSr9/gtI12Kf+pF1fWZ3YZyTs/fTO6sLnUOjJGIkM6AaYZvqlt7E+aPXT51g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1685207357; x=1685293757; bh=j 7FpUM00K7Z38vMF6hRGIqeTfMQAoGL+JYlszghlNlE=; b=of8Pxuk82Rv+oSYDZ fr5FwqIB8xnwBjyQG3gyDW9XfedToeOFg5jeAYb7oRgCCJHXSrKWhbJtC7cLMz0H YmXsvs26QVZ50zKlJO1fxv/KXoDx8/3jFhn4/KsMehDu9iXsHCGNSedcswisN9Qt 4QbjU2nmJI/ZJd3h2dqXeGc0PcBRuhqiGsCEvci0VNAaVlhPXsSAbMyCjhEr/IZ4 C9WW+h0rbhtP9Psy6oC2wVWVITsrzq0+LH/T/2yluNVBMEqAJnXs7fw9ORmaEXHM oSMAXwjLkFFdv7nUrWPX4j4oMh+KBznNhGkrDs01lnxvPgY0kCaKJghEDdYLQAGo n9QrQ==
X-ME-Sender: <xms:PTlyZDWWS2UxTSCcwReBRfvNY7Gjv6Lci6u9NZG03mNLryGTWLbt7w> <xme:PTlyZLmu9MAvI3UBkGbFYm2qgkl0IOSCSBFa9eivTCkV9Yv_JT0eAhk69cnMNlVPL kJZ424UMvC7Y_n86Q>
X-ME-Received: <xmr:PTlyZPbyFHV22Q9EJVL-i5cnaOsy6mawSLezi08tfYgKual-ghU9QuY>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeekuddguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecufghrlhcuvffnffculddqiedmnecujfgurheprh fhvfevfhgjufffohfkgggtofhtsehrtdhgpedvtdejnecuhfhrohhmpedfffhitghkuceu rhhoohhkshdfuceoughitghksehrvghlihgrsghlvggvnhgvrhhghigrnhgrlhihthhitg hsrdgtohhmqeenucggtffrrghtthgvrhhnpeeguefguefggeejveduleffudetueefteeh ledugefhfeduffekudevgfeugefgveenucffohhmrghinhepnhhishhtrdhgohhvpdhrvg hlihgrsghlvggvnhgvrhhghigrnhgrlhihthhitghsrdgtohhmpdhgihhthhhusgdrtgho mhdpihhnthgvlhdrtghomhdpvghinhhprhgvshhsfihirhgvrdgtohhmpdhivghtfhdroh hrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ihgtkhesrhgvlhhirggslhgvvghnvghrghihrghnrghlhihtihgtshdrtghomh
X-ME-Proxy: <xmx:PTlyZOXi3z-xenq4isATkAFx0Tjxshs3yi9i6a7m5Fw7qfnVBCwnuA> <xmx:PTlyZNkdjVXneWDL6c2vHqK5DG6zCY38We18YDxpmPqFsrvlpN9NRw> <xmx:PTlyZLdH2WgQyP0Np4pGH-QQSWGiGLu02jneWRPeJDv7R4WsVEZSuA> <xmx:PTlyZDhNqGOO8LziW9VmIz3QYF6bjEWMLdOM5jXQFYkxZRmaZjQnGQ>
Feedback-ID: i57d944d0:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 27 May 2023 13:09:16 -0400 (EDT)
Reply-To: dick@reliableenergyanalytics.com
From: Dick Brooks <dick@reliableenergyanalytics.com>
To: 'John Andersen' <johnandersenpdx@gmail.com>
Cc: ofcio@omb.eop.gov, scitt@ietf.org, 'scrm-nist' <scrm-nist@nist.gov>, 'swsupplychain-eo' <swsupplychain-eo@nist.gov>
References: <238d01d990ad$81b699b0$8523cd10$@reliableenergyanalytics.com> <CAPFAYiVeq0Y+4U=yjia6CvpsXEC6HbtunHkj07SMp2X+Mz+ZfA@mail.gmail.com>
In-Reply-To: <CAPFAYiVeq0Y+4U=yjia6CvpsXEC6HbtunHkj07SMp2X+Mz+ZfA@mail.gmail.com>
Date: Sat, 27 May 2023 13:09:14 -0400
Organization: Reliable Energy Analytics LLC
Message-ID: <242d01d990bd$f8423ed0$e8c6bc70$@reliableenergyanalytics.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_242E_01D9909C.71309ED0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGtoQ4c+B6TqAZxglWuG/ovVVgzAwJd05bjr7NI/uA=
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/scitt/IQbvLGApy3HpxUkZ610SUKLUOzQ>
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:09:23 -0000

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:dick@reliableenergyanalytics.com> 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 <mailto: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

 

 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

 <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com

Email:  <mailto:dick@reliableenergyanalytics.com> dick@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

-- 
SCITT mailing list
SCITT@ietf.org <mailto:SCITT@ietf.org> 
https://www.ietf.org/mailman/listinfo/scitt