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

[Dick Brooks <[e-mail]>]

Orie,

 

Thanks for clarifying.

 

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:[e-mail]> [e-mail]

Tel: [phone]

 

 

From: Orie Steele <[e-mail]> 
Sent: Monday, February 19, 2024 1:30 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [SCITT] Question regarding Transparency Service query results and registration policy

 

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] <mailto:[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

 

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

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

Email:  <mailto:[e-mail]> [e-mail]

Tel: [phone]

 

 

From: Orie Steele <[e-mail]> 
Sent: Monday, February 19, 2024 12:50 PM
To: [e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[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] <mailto:[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

 

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

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

Email:  <mailto:[e-mail]> [e-mail]

Tel: [phone]

 

 

From: Orie Steele <[e-mail]> 
Sent: Monday, February 19, 2024 12:30 PM
To: [e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[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] <mailto:[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

 

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

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

Email:  <mailto:[e-mail]> [e-mail]

Tel: [phone]

 

 

From: Orie Steele <[e-mail]> 
Sent: Monday, February 19, 2024 11:41 AM
To: [e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[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] <mailto:[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

 

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

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

Email:  <mailto:[e-mail]> [e-mail]

Tel: [phone]

 

 

-- 
SCITT mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/scitt




 

-- 

 

ORIE STEELE
Chief Technology Officer
www.transmute.industries

 <https://transmute.industries/> 




 

-- 

 

ORIE STEELE
Chief Technology Officer
www.transmute.industries

 <https://transmute.industries/> 




 

-- 

 

ORIE STEELE
Chief Technology Officer
www.transmute.industries

 <https://transmute.industries/> 




 

-- 

 

ORIE STEELE
Chief Technology Officer
www.transmute.industries

 <https://transmute.industries/>