Telechat Review of draft-ietf-scitt-architecture-20
review-ietf-scitt-architecture-20-iotdir-telechat-livingood-2025-09-12-00

This is an interesting proposal and very worth proceeding with in the IETF.

There is a question about its practicality, but that will only become clear in
future Internet-Drafts that build on this architecture. The architecture
attempts to create a broader SBoM of sorts that covers the entire supply chain
of software generation (much like what SDL tries to do, but for packaged
released software). SCITT is something of a mix between a Cyber TrustMark and
an SBoM. It does mention crypto agility considerations in its own architecture
which is nice.ÊThis document also makes a very good case for why software
producers (not users) should be held to higher security standards.

This document proposes a data structure (SCITT) for software supply chain (not
limited to OSS). This is for the entire pipeline, not just SBoMs, which apply
only to packages or third-party dependencies. It shows a gap in what SBoMs can
cover, by putting together an architecture to make sure specific security
measures implemented at every stage (from code to deployment) is verifiable in
a unified schema. Furthermore, every security measure at every stage of the
supply chain is signed with proof.Ê

I really like the idea of having a unified ÒlabelÓ of sorts that can account
for all facets of software supply chain. It also accounts for Òadd-on servicesÓ
depending on the software and the use case. However, it has the same problems
as having an IoT label, like information overload, inaccurate data, and lack of
interest in implementation without a push from a regulator.

Nit: I am not sure which fields are deemed required versus voluntary.

Minor Observation: The document assumes that the software producer has enough
resources to immediately fix a vulnerability so that it does not show up on the
transparency chain. Most small scale software providers will likely not change
anything in their process due to the transparency from SCITT due to other
release considerations.Ê

Minor Observation / Possible Nit: What are the security measures to mitigate
security vulnerabilities in the SCITT schema itself? Beyond saying that
sensitive information should be hashed locally before sending to the
transparency service, there are no additional security considerations (the
document mentions these are out of scope though and should follow standard
security practices recommended by IETF). The only privacy consideration is that
SCITT issuers must check that providers donÕt have PII (which historically
doesnÕt work in practice well). If I was an attacker, I can go ahead and modify
the output of this schema to include false provenance and security statements.