ietf-scitt / use-cases

SCITT Use Cases
Creative Commons Zero v1.0 Universal
4 stars 6 forks source link

Minimal viable capabilities of SCITT, from a consumer perspective #26

Open rjb4standards opened 2 years ago

rjb4standards commented 2 years ago

This scenario includes a notary examining 3 artifacts provided by a software vendor for registration into a SCITT registry where consumers can verify that these artifacts, and their digital signature are trustworthy - based on a trustworthy SCITT notary process to be defined in a SCITT standards track RFC. The 3 artifacts are located here along with their digital signature materials: https://github.com/rjb4standards/SCITT-MVP-USeCases SBOM: https://github.com/rjb4standards/SCITT-MVP-USeCases/blob/main/SAG-PM_SBOM_V1_2.xml VDR: https://github.com/rjb4standards/SCITT-MVP-USeCases/blob/main/SAG-PM_VulnDisclosure_V1_2.xml VRF:https://github.com/rjb4standards/SCITT-MVP-USeCases/blob/main/SAG-PM_VendorResponse_V1_2.xml

NOTE: Each of these artifacts are actual production artifacts for REA's SAG-PM V1.2 product.

A Vendor Response File is provided by a software vendor to software consumers to aid in discovery and distributions of software supply chain artifacts. An article describing a VRF is available online: https://energycentral.com/c/pip/advice-software-vendors-prepare-omb-m-22-18-requirements

A notary, after completing the trustworthy SCITT notarization process create a claim "trust declaration" and places this into a SCITT Registry, where consumers can query the trustworthiness of each artifact against the SCITT registry.

Here is an example of a consumer interaction with a SCITT registry querying for trust declarations for the SBOM artifact using a SHA-256 hash value of the SBOM artifact and the secret key ID used to sign the SBOM, usign a REST api call:

https://softwareassuranceguardian.com/REA_api/gettrustData?REACUSTID=SCITT_HACKATHON&FileHash=A0F8A0B3FEB6D89947CC4F6ABF420E1EFBE4EB1EAF90B77203683904B0C9DD85&SKID=2C17B5D1A50EA9144AAF8DD6D4EB22CCB8A6A3AB

A SCITT registry would return some information about any trust declarations that are present in the SCITT registry in response to the API Call:

[{"NotaryName": "IMA SCITT Notary", "CreateDateTimeUTC": "2022-10-24T19:14:44.747627", "SignerOrgName": "Reliable Energy Analytics LLC", "SourceSupplierName": "Reliable Energy Analytics LLC", "ProductName": "SAG-PM (TM)", "ProductVersion": "1.2", "FileName": "SAG-PM_SBOM_V1_2.xml", "StartDateTimeUTC": "2022-10-24T19:14:44.747627+00:00", "EndDateTimeUTC": "9999-12-31T17:00:00+00:00", "SAGScore": 89}]

SteveLasker commented 2 years ago

Thanks @rjb4standards, These look like great examples. A doc that stitches together how they would be used, while providing links to these would help drive some clarity to how SCITT is used to support multiple evidence formats.

Suggestion:

rjb4standards commented 2 years ago

Steve,

Please look at issue 26 and let me know if this addresses your suggestions

https://github.com/ietf-scitt/use-cases/issues/26#issue-1427191203

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: @.> @.

Tel: +1 978-696-1788

From: Steve Lasker @.> Sent: Monday, October 31, 2022 5:55 PM To: ietf-scitt/use-cases @.> Cc: Dick Brooks @.>; Mention @.> Subject: Re: [ietf-scitt/use-cases] Minimal viable capabilities of SCITT, from a consumer perspective (Issue #26)

Thanks @rjb4standards https://github.com/rjb4standards , These look like great examples. A doc that stitches together how they would be used, while providing links to these would help drive some clarity to how SCITT is used to support multiple evidence formats.

Suggestion:

— Reply to this email directly, view it on GitHub https://github.com/ietf-scitt/use-cases/issues/26#issuecomment-1297732952 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFI3NHU6GMIIAFLFOO5PIDWGA52TANCNFSM6AAAAAARRAZZAA . You are receiving this because you were mentioned.Message ID: @.***>