Re: [SCITT] Question regarding Transparency Service query results and registration policy

[Orie Steele <[e-mail]>]

A "registration policy" is the policy a vendor sets for deciding what
criteria a "signed statement" must meet, in order for the vendor to provide
a receipt.

For example, a vendor might require the COSE Sign1 to be signed by issuers
or certificates that are in a specific PKI (Public, Private), or that are
about a specific subject, such as a product identified by a PURL, or any
other product identifier.

A registration policy is not a place to "define APIs".

The registration policy is expected to be applied to every message that is
sent to a SCITT API Endpoint that "accepts signed statements and produces
receipts".

However, the provisioning, maintenance and definition of the policy is out
of scope for SCITT.

AFAIK, the current SCITT API endpoints are not mandatory to implement at
all, meaning there is no assurance of interoperability or conformance to a
specific set of HTTP endpoints for SCITT.

Some vendors might choose to never implement any of these SCITT HTTP APIs
and instead expose the "scitt registration apis" over gRPC, Kafka, or some
other transport.

If vendors do advertise compatibility with
https://datatracker.ietf.org/doc/draft-ietf-scitt-scrapi/
Then the normative requirements of that document apply, and those
requirements are what enable interoperability over that specific HTTP API.

I'd stress that SCRAPI is just "one HTTP" API, and since it's not mandatory
to implement, it may provide little to no interoperability.

OS


On Mon, Feb 19, 2024 at 12:07 PM Dick Brooks <
[e-mail]> wrote:

> I am not suggesting that every vendor produce a trust score.
>
>
>
> I’m asking a question “Should SCITT vendors be expected to define their
> API’s in a Registration Policy” OR will the SCITT API define the specific
> API’s that need to be supported by each vendor?
>
>
>
> 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: [e-mail]
>
> Tel: [phone]
>
>
>
>
>
> *From:* Orie Steele <[e-mail]>
> *Sent:* Monday, February 19, 2024 12:50 PM
> *To:* [e-mail]
> *Cc:* [e-mail]
> *Subject:* Re: [SCITT] Question regarding Transparency Service query
> results and registration policy
>
>
>
> Are you suggesting that some vendors who build products on SCITT, might
> require a "trust score" as part of their registration policy?
>
> Seems like they are allowed to do that today.
>
> If you are asserting that all registration policies should mandate such a
> check, I can imagine that might produce objections.
>
> As a general rule, vendor or domain specific registration policies seem to
> be out of scope for SCITT, although there is still debate about what is "in
> scope" for "mandatory to implement" registration policies.
>
> OS
>
>
>
> On Mon, Feb 19, 2024 at 11:38 AM Dick Brooks <
> [e-mail]> wrote:
>
> Orie,
>
>
>
> I agree: Seems to me that something *like* this might be a better fit for
> the current SCITT APIs:
>
> My question is: Will SCITT define the API interfaces and return results of
> will this be a matter for the “Registration Policy” to address?
>
>
>
> I’m not proposing any interface standards, just trying to understand how
> this functionality will be accommodated by SCITT; in the spec or in the
> registration policy, or some other method?.
>
>
>
> 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: [e-mail]
>
> Tel: [phone]
>
>
>
>
>
> *From:* Orie Steele <[e-mail]>
> *Sent:* Monday, February 19, 2024 12:30 PM
> *To:* [e-mail]
> *Cc:* [e-mail]
> *Subject:* Re: [SCITT] Question regarding Transparency Service query
> results and registration policy
>
>
>
> I don't see APIs like this in any of the IETF documents.
>
> Do you feel this API is essential to SCITT protocol interoperability?
>
> Can you explain why it would help Vendors A and B to agree to host such
> API endpoints, and how they might be used in a "federation" use case?
>
> Seems to me that something *like* this might be a better fit for the
> current SCITT APIs:
>
> GET
> https://vendor.a.example/receipts/urn:...ietf:scitt:signed-statement:sha256:base64url:<hash
> of signed statement>
> ~> proof that a vendor recorded a signed statement regarding a "trust
> score for a product" in their log.
>
> The "signed statement part", would be a COSE Sign1 over the JSON payload
> your current API is returning as a result.
>
> The use case for this would be, in the event of an incident, the response
> team could forward the receipt to the vendor who issues the receipt,
> when asserting that a product was "known to have a low score", and that
> its potentially the entry point of an exploit chain.
>
> OS
>
>
>
> On Mon, Feb 19, 2024 at 10:48 AM Dick Brooks <
> [e-mail]> wrote:
>
> Thanks Orie.
>
>
>
> Here is an example of a “Transparency Service” query, that I’m thinking of
> for scrapi:
>
>
>
> I’m thinking a “Transparency Service” will need to describe it’s API
> service interfaces and results returned, including errors.
>
> Query API:
>
>
> https://softwareassuranceguardian.com/SAGCTR_inquiry/getSAGScore?FileHash=48E0EEB4C538BCD65514D68DDA5E1B41BE9F38AAB3A9B4108F056A27BE1F379A
>
>
>
> JSON Results Returned:
>
>
>
> [{"SAGScore": 88.65, "current_date": "2024-02-19", "SourceSupplierName":
> "Reliable Energy Analytics LLC", "ProductName": "SAG-PM (TM)",
> "ProductVersion": "1.2.2", "Label Type": "SAG Trusted Software", "Product
> Category": "Desktop Software Application"}]
>
>
>
> Here is an example of an error result:
>
>
>
> https://softwareassuranceguardian.com/SAGCTR_inquiry/getSAGScore?FileHash=
>
>
>
> JSON Results Returned:
>
>
>
> {"SAGresult":"Invalid Request"}
>
>
>
>
>
>
>
>
>
> 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: [e-mail]
>
> Tel: [phone]
>
>
>
>
>
> *From:* Orie Steele <[e-mail]>
> *Sent:* Monday, February 19, 2024 11:41 AM
> *To:* [e-mail]
> *Cc:* [e-mail]
> *Subject:* Re: [SCITT] Question regarding Transparency Service query
> results and registration policy
>
>
>
> https://datatracker.ietf.org/wg/scitt/documents/
>
> ^ unless it's in one of these documents, or an issue in one of the
> repositories for working on them, or a thread on this list that is clearly
> showing consensus to do something.
>
> It's not a thing the IETF WG is developing.
>
> I think the answer to your question is "No", but having the IETF documents
> not define this, does not preclude vendors from developing products that
> build on SCITT that do this.
>
> One way to think about what should be done in the IETF documents vs in
> products build on the IETF documents is to answer this question:
>
> Is interoperability at this layer essential to solving the problem we are
> chartered to solve.
>
> Some examples of what you mean by "API Query Results" might make it easier
> for the list to answer this question.
>
> Regards,
>
> OS
>
>
>
> On Mon, Feb 19, 2024 at 10:22 AM Dick Brooks <
> [e-mail]> wrote:
>
> Will a Transparency Service specify it’s “API query results” within the
> registration policy OR will SCITT require a Transparency Service to provide
> a catalog of supported API’s and their interface definitions? Or both?
>
>
>
> 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: [e-mail]
>
> Tel: [phone]
>
>
>
>
>
> --
> SCITT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scitt
>
>
>
>
> --
>
>
>
>
> *ORIE STEELE*Chief Technology Officer
> www.transmute.industries
>
> [image: Image removed by sender.] <https://transmute.industries/>
>
>
>
>
> --
>
>
>
>
> *ORIE STEELE*Chief Technology Officer
> www.transmute.industries
>
> [image: Image removed by sender.] <https://transmute.industries/>
>
>
>
>
> --
>
>
>
>
> *ORIE STEELE*Chief Technology Officer
> www.transmute.industries
>
> [image: Image removed by sender.] <https://transmute.industries/>
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>