Create a platform for interoperability tesing between interested parties

[rjb4standards]

Please consider setting up a "Transparency Service" SCRAPI endpoint where people can test their "issuer" code and receive feedback on any issues, in real-time OR a receipt, as expected.

[ivarprudnikov]

It would be great but there are practical challenges to having something like it. Instead, for now at least, we have demo scripts for anyone to run it locally.

Using demo scripts on your host

The scripts are numbered and run on non confidential compute hardware. The starting point and readme is in /demo/transparency-service-poc. The user would spin up the API locally and would be able to crease expected signing envelopes with an expected issuer to pass the registration policy.

Using Codespaces in GitHub

There is also a way to quickly run it in a Codespace which is mentioned in /DEVELOPMENT.md:

1. 
2. Once open, run build in terminal ./build.sh
3. Then start the server ./start.sh
4. Once the server is running, open it up in another terminal ./pyscitt.sh governance local_development --url https://127.0.0.1:8000
5. The server will be able to accept the payloads at https://127.0.0.1:8000 for any issuer at phdr.cwt.iss. If you have a valid cose you can submit it.

Some of the challenges

The main challenge is in the signing infrastructure, that is, which identities we should trust in this demo instance. If you look at the demo it will render itself naturally, i.e. how the self signed key identity gets propagated to the policy to trust it. There is no openly available signing identity for now that could create the envelopes we need to test the submissions yet. The reason we'd need an openly available identity is to expect it in the verification policy, or do we want to allow anyone to submit?

Another unanswered question is if we need confidential compute or a simple test server would be enough. Our idea is very much to rely on conf compute. Without it the demo might misrepresent what the software does. On the other hand it is expensive to run and maintain and we have some restrictions in place which prevent us easily running it and opening to the anonymous traffic.

What is more the question is which draft version is supported. It is quite difficult to be on the bleeding edge at the moment for us. For now we document the alignment in /docs/scitt.md. But would that be enough?

[rjb4standards]

Thanks for the insight Ivar.

We faced this same challenge, because we support self-signed certificates "The main challenge is in the signing infrastructure, that is, which identities we should trust in this demo instance"
We decided to use the Trust Registry itself to answer the question "Is this key trusted?" Using the public X.509 certificate as input, you can see how this works at: https://github.com/rjb4standards/REA-Products/tree/master/DigitalCertificates

It's a simple powershell script that does a trust lookup for the X.509 public key certificate in SAG-CTR. See if this meets your needs and I'll test with you using the public key on Github

[ivarprudnikov]

We use did:x509 issuers, the envelope also contains the cert chain. We avoid making network calls in the verification process because the issuer string is bound to the cert chain which is provided already. This way we verify the chain in place and check if the issuer string represents it. The policy does additional checks post the signature envelope integrity check, e.g. do you trust that specific CA and EKU and other details. The policy effectively is a location where you list all trusted issuers in our instance.

[rjb4standards]

Thanks for your quick response. If this is indeed what you are doing "We avoid making network calls in the verification process because the issuer string is bound to the cert chain which is provided already." then this means you are not checking CRL's to confirm that the certificate is still trustworthy. I don't beleive it will be viable to assume a certificate is trustworthy becasue of the certificate signing chain. You MUST validate that a certificate is trustworthy using a CRL/OSCP lookup or the approach we use with SAG-CTR. NOTE: self-signed digital certificates can also be verified using the SAG-CTR trust lookup method.

This is why organizations like Google are moving beyond PKI to Public Trust Infrastructure (PTI) Trust Registries; https://blog.google/security/bringing-binary-transparency-to-the-android-ecosystem/ where Never trust, always verify is the modus operandi.

[ivarprudnikov]

You MUST validate that a certificate is trustworthy

For now the operator has full control over which CAs are trusted, it is explicit in the policy, we do not have a default list. If the certificate needs to be revoked then the policy needs to be updated for that CA reference to be removed.

[rjb4standards]

Every Public CA issuing X.509 digital certificates provide links to a CRL so that each certificate can be checked for validity. If you are not checking the CRL's than you are assuming that a certificate is still valid because the CA is still valid.

CRL Endpoints Distribution Point
http://crl.godaddy.com/gdr1v1dv_s1-3.crl

[ivarprudnikov]

I think what you are saying is that the current implementation of CA monitoring outside of the verification event is not something you prefer, specifically when using Public CAs. So far we worked with the internal signing systems and an explicit management of CA validity including its removal/revocation. Even the ledger itself, when boots, uses a self signed cert originating in hardware for TLS, i.e. not using a public CA.

There is another type of the signing method we support as well, which involves hardware identities using did:attestedsvc type of an issuer if that would be of interest, see /docs/inputs.md

I'll see if our team has something more to offer in the case of CRL/OSCP revocation lists. Would that be a blocker for you in case it is absent at the moment?

[rjb4standards]

It is not a blocker for us because we are already working with the IETF SCITT community to serve as the Merkle Tree Ledger that SAG-CTR will use for "auditing purposes". The ultimate question we still need an answer to is "Will Microsoft's SCITT Ledger/Transparency Service accept our self-signed certificate COSE envelopes?'

If self-signed certificates COSE signed statements are not going to be accepted by the Microsoft SCITT Transparency Service then we will need to seek other options.

You may also want to consider supporting "Zero Trust" implementations in your designs by adding ztdnaid's to your list of did identifiers: https://www.ietf.org/archive/id/draft-brooks-ztdnaid-new-02.txt

Lastly, trust verification functions must be high performance, completing in under one second. We achieve this today in SAG-CTR by keeping a local cache of trusted objects that are stored on the SCITT Ledger. The SCITT Ledger primarily serves as a "validation for auditing purposes proving that the SAG-CTR results are valid". We intend to provide a link to the SCITT Receipt URL, as shown in this trust label lookup for the curl product (note response time for this lookup): https://softwareassuranceguardian.com/labellink/getTrustedProductLabel?ProductID=642A07EEEA4D3132426E673FB3C88BE8CEAD3D03CA1F019C7E7D0000ED2122BE&html=1

[ivarprudnikov]

Will Microsoft's SCITT Ledger/Transparency Service accept our self-signed certificate COSE envelopes?

• You could try submitting your signature using a locally running instance to check if all is good
  • Aside from that there is no single Microsoft ledger open for the public to submit data to and expect it to be accepted at the moment
• The cose envelope max default size limit is 1mb, it is possible to configure it if you run your own instance, this is especially important in case you have large SBOMs as in that case we'd use COSE Hash envelope or some JSON descriptor instead, the main challenge is to make sure large files do not get stored in the ledger, hence the hard limit
• If you have a sample signature we could add it to the CI tests, e.g. at

  scitt-ccf-ledger/test/test_cli.py

  Lines 236 to 276 in 97f0b25

  	@pytest.mark.parametrize(
  	"filepath",
  	[
  	"test/payloads/cts-hashv-cwtclaims-b64url.cose",
  	"test/payloads/manifest.spdx.json.sha384.digest.cose",
  	"test/payloads/css-attested-cosesign1-20250925.cose",
  	"test/payloads/css-attested-cosesign1-20260302.cose",
  	],
  	)
  	def test_submit_and_validate(
  	run, tmp_path, client: Client, configure_service, filepath
  	):
  	allow_all_policy_script = "export function apply(phdr) {return true}"
  	configure_service({"policy": {"policyScript": allow_all_policy_script}})
  	with open(filepath, "rb") as f:
  	cts_hashv_cwtclaims = f.read()
  	statement = client.submit_signed_statement_and_wait(
  	cts_hashv_cwtclaims
  	).response_bytes
  	(tmp_path / "transparent_statement.cose").write_bytes(statement)
  	# Fetch service keys from /.well-known/scitt-keys (COSE_Key_Set in CBOR)
  	keys_resp = client.get("/.well-known/scitt-keys")
  	keys_resp.raise_for_status()
  	(tmp_path / "trust_store").mkdir(parents=True, exist_ok=True)
  	(tmp_path / "trust_store" / "scitt-keys.cbor").write_bytes(keys_resp.content)
  	run(
  	"validate",
  	tmp_path / "transparent_statement.cose",
  	"--service-trust-store",
  	(tmp_path / "trust_store"),
  	)
  	run(
  	"pretty-receipt",
  	tmp_path / "transparent_statement.cose",
  	)

  to make sure the issuer is accepted and the verification of the chain passes.

trust verification functions must be high performance, completing in under one second

I am not fully following what this refers to. Transparent statement verification is fast if you have the public keys, it can be performed offline, e.g. see test test_validate_print_issuers Our inclusion verification effectively tells you that signed statement was accepted and registered using the specific registration policy at that time, all being openly traceable. If this refers to being able to download the transparent statement as well then additional milliseconds must be allocated.

[rjb4standards]

Please, Microsoft, consider setting up a public sandbox server of CCF 0.18.1 so that external parties can test directly with the team and report on any issues in testing.
Thanks for you consideration.