An Architecture for Trustworthy and Transparent Digital Supply Chains
draft-ietf-scitt-architecture-22

# Éric Vyncke, INT AD, comments for draft-ietf-scitt-architecture-20
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Amaury Chamayou for the shepherd's write-up including the WG consensus _and_ the justification of the intended status.

Other thanks to Jason Livingood, the IoT directorate reviewer (at my request), please consider this iot-dir review:
https://datatracker.ietf.org/doc/review-ietf-scitt-architecture-20-iotdir-telechat-livingood-2025-09-12/ (I have not seen any reply by the authors, this review is to be considered as a IETF Last Call one, i.e., comments MUST be addressed)

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### IoT Directorate review

The IoT directorate review comments have not been addressed, and they should be considered as any other IETF Last Call comments. I am trusting the responsible AD to ensure that the comments will be addressed.

### Section 1

Suggest to split the very long paragraph one in 3 parts: problem to be solved, how to solve it, benefits. A graphical representation would also help to understand all the interactions (e.g., a simplified version of the nice Figure 2).

The reader has often to read a very long paragraph in this document, while perfectly correct, this does not help the reader.

### Section 2.1

Isn't it weird to have a generic section 2.1 included in a specific 'software-only' section 2 ?

BTW, thanks for using SVG graphics they are so much nicer in HTML rendering.

### Section 2.2.3

Is this short section about autonomous véhicle useful ?

### Section 3

Should "CWT" be expanded (and informational reference added) ?

### Section 5.1.1.1

s/ Transparency Service MUST, at a minimum,/ Transparency Service MUST/ ?

Please add a reference to `x5t` or define it. Same for `kid` used later in the text, especially since "kid" is a common English word.

### Section 5.1.3

It is unclear (at least to me but perhaps to other implementers) whether draft-ietf-cose-merkle-tree-proofs is the only way to be implemented.

### Section 6

The list of references to other documents would benefit from adding a few words describing the reference.

Thanks for making this document. I have reviewed this from a transport layer perspective and have no technical comments.

I was confused by the text around word "notary", but note that I now see that US usage appears to have a different meaning to that with which I am accustomed. Maybe to be kind to others, it might be helpful just to omit the text trying to parallel this with a human notary?

The text also says: "such as Certificate Transparency", could a (cross) reference be added to explain what that is?

Thanks to the authors and the WG for their work on this document.

I have a couple of comments:

1) I could not find a reference to RFC 9334. Please remove from references if unused.

2) I am not following the intent of section 10.1. If IANA has already done the allocation via another document then it is not required to be mentioned in the IANA consideration section of this document. That codepoint can be directly referenced as is being done in section 7. Section 10.1 can be deleted.

Given the varying functions performed by [notaries in different legal systems](https://edictsandstatutes.com/notaries-in-different-cultures/#The_Role_of_Notaries_in_Diverse_Legal_Systems), the comparison to a notarial stamp might be more confusing than illuminating for a global audience. For example, in the US, a notary certifies the identity of the signer without verifying the accuracy of the document being signed ("confirm a policy is met before recording the statement").

In Section 2.1, please expand and/or link to a definition of the term "DevSecOps".

I appreciate the thorough Terminology section. The definition of Non-equivocation uses the capitalized term "Single Verifiable Data Structure"; while I see "Verifiable Data Structure" defined, there's no definition of the capitalized Single or of SVDS as a term. Should this be "single Verifiable Data Structure" or is an additional definition needed?

In Figure 2, I'm unclear why there's a line from Issuer's "verify" to the Transparency Service. Wouldn't that go only into Verify Transparent Statement?

The claims being used (`iss`, `sub`) are from RFC8392. That's referenced to define the term "claim", but isn't given as a reference for these specific claim types. Please expand on that reference so people can follow that thread.

Similarly, there's no introduction to `x5t`, `x5chain`, or `kid`. From context, I assumed they came from COSE_Sign1 in RFC 9052, but I don't find them there. Can you put pointers as appropriate? If this document is defining them, be clearer about that.

In Section 9.5, what does "normatively signed" mean? If it means the media type requires a valid signature, consider "which include a signature and therefore...."

In Section 9.7, "blame" may be a more loaded word than you want. I think this is trying to make a statement about attribution, not fault.

===NITS FOLLOW===
Section 2.1, "cyber security-based" => "cyber-security-based"
Section 3, "for implementations" => "for implementations."
Section 5.1.4 ends with a sentence fragment. Should this be part of the previous sentence?
Section 6, no commas around the parentheses in the last paragraph
Section 7.1, no comma after "[STD96]"
Section 9.2, "unintentionally," => "unintentionally;"
Section 9.5 and multiple Figures, "COSE Sign1" => "COSE_Sign1"?

Hi Henk, Antoine, Cédric, Yogesh, and Steve,

Thank you for the effort put into this very well-written document. 

Please find below some comments:

# (meta comments) Operationalization matters

Many questions popped up when reading the document (e.g., how the various entities know/discover each other, how authentication is done, how bootstrapping is made, what registration actually means, how the receipts are retrieved, how collection is made, how the latest version of a statement on a specific component is made available rather than consuming a stale one, what if a TS is not available anymore, etc.

As this is an architecture document (but not only), I was expecting some of these details to be grouped in a single place (even with a statement, these are out of scope).

# On scalability and flexibility

CURRENT (Abstract):
   This document proposes a
   scalable architecture for single-issuer signed statement transparency
   applicable to any supply chain.  It ensures flexibility,
   interoperability between different transparency services, and
   compliance with various auditing procedures and regulatory

(1) It is not clear to me how what means “scalable architecture” here. Scalability can be approach from various angles and I’m not sure which aspects is being focused on here. I’d prefer we back any claim here with a discussion on that in the main text.

(2) Likewise, what does flexibility mean in this specific context? For example, there are some constraints imposed on how registration policies may be updated, etc. I think that exercising the architecture and playing with various contexts (complex component dependencies, other uses) would be needed first.

(3) Idem, maybe I’m misreading this but what aspect in the spec you have in mind with “interoperability between different transparency services”?

(4) nits

* s/proposes/defines

* Not easy at this stage to digest what is a “transparency service”.

# How domain is defined in this specific context?

CURRENT (S.1):
   As these messages provide the foundation of
   any transparency service implementation for global and cross-domain
                                                          ^^^^^^^^^^^^
   application interoperability, they are based on complementary COSE
   specifications, mainly [I-D.draft-ietf-cose-merkle-tree-proofs].

# Figure 1: These are still possible attacks. I don’t think we sat  that SCITT will nullify those. Right?

# DevSecops

CURRENT (S.2.1):
  DevSecOps often depends on third-party and open-source software. 

I know what it means, but do we have an authoritative ref to cite for DevSecOps?

# CWT_Claims

CURRENT (S.3):
      In SCITT
      Statements and Receipts, the iss CWT Claim is a member of the COSE
      header parameter 15: CWT_Claims within the protected header of a
      COSE Envelope.  

(1) I don’t find CWT_Claims in the base COSE spec. 

(2) I guess we meant what is defined in RFC9597. If so, please add a pointer to that RFC.

(3) Also, I think this and other occurrences in the document should be “CWT-Claims” to comply with 9597.

# Receipts

CURRENT (S.3):
   Receipt:  a cryptographic proof that a Signed Statement is included
      in the Verifiable Data Structure.  See
      [I-D.draft-ietf-cose-merkle-tree-proofs] for implementations
      Receipts are signed proofs of verifiable data-structure
      properties.  The types of Receipts MUST support inclusion proofs
      and MAY support other proof types, such as consistency proofs.

(1) I don’t parse the second sentence.

(2) What is a “type of receipt”? Failed to find which part of draft-ietf-cose-merkle-tree-proofs this is referring to.

(3) Weird to have the normative requirement in a terminology section.

# SCITT instance

CURRENT (S.4):
   A SCITT instance is referred to as a Transparency Service.

Isn’t SCITT about the full architecture?

Also, I don’t see “ SCITT instance” used anywhere in the document.

# Mixing state and roles

Figure 2 is mixing state, entities, and so on. Also the direction of arrows is confusing to me. For example, I expect sign and verify to act in distinct directions.

No clear to me how to read this diagram.

# Concretely

CURRENT (S.5.1):
  Transparency Services MUST feature a Verifiable Data Structure.  

What does concretely mean?

# Maintain

CURRENT (S.5.1.1):
   Transparency Services MUST maintain Registration
   Policies.

What does this concretely imply?

# is there any value to notify the change to any other entity in the architecture when such event happens/planned?

CURRENT (S.5.1.1.2):
   The operator of a Transparency Service MAY update the Registration
   Policy or the trust anchors of a Transparency Service at any time.

# Enough information

CURRENT (S.5.1.1.2):
   Transparency Services MUST ensure that for any Signed Statement they
   register, enough information is made available to Auditors to
   reproduce the Registration checks that were defined by the
   Registration Policies at the time of Registration.

Can we list a minimum information to be logged and made available?

# Standard COSE implem

CURRENT (S.6):
   Once all the Envelope headers are set, an Issuer MUST use a standard
   COSE implementation to produce an appropriately serialized Signed
   Statement.

That is?

Cheers,
Med

Thank you to Roni Even for the GENART review.

** Idnits reports:
  == Unused Reference: 'RFC9334' is defined on line 1699, but no explicit
     reference was found in the text

** Section 2.1
   Lastly, where data exchange underpins serious business decision-
   making, it is important to hold the producers of those data to a
   higher standard of accountability. 

Defining the degree of accountability for producers is not in-scope for the charter.

** Section 2.2.3.  What about this use case is unique to an “autonomous vehicle”, as opposed to a “non-autonomous vehicle” or “any vehicle”? 

** Section 4
   Reputable Issuers are thus incentivized to carefully review their
   Statements before signing them to produce Signed Statements.
   Similarly, reputable Transparency Services are incentivized to secure
   their Verifiable Data Structure, as any inconsistency can easily be
   pinpointed by any Auditor with read access to the Transparency
   Service.

What makes an issuer or transparency service “reputable”?

** Section 4
   The building blocks defined in SCITT are intended to support
   applications in any supply chain that produces or relies upon digital
   Artifacts, from the build and supply of software and IoT devices to
   advanced manufacturing and food supply.

This statement is outside the scope of the SCITT charter.

** Section 5.
   The SCITT architecture enables a loose federation of Transparency
   Services, by providing a set of common formats and protocols for
   issuing and registering Signed Statements and auditing Transparent
   Statements.

Where is the basis for this “federation” explained?  What does it mean to be “federated”?

** Section 5.1.1.1.  What is a “COSE-compatible trust anchor”?

** Section 6
   Once all the Envelope headers are set, an Issuer MUST use a standard
   COSE implementation to produce an appropriately serialized Signed
   Statement.

What is a “standard COSE implementation”, as opposed to using COSE?

** Section 9.4
   Issuers and Transparency Services MUST:
…
   *  rotate their keys in well-defined cryptoperiods, see
      [KEY-MANAGEMENT]

What makes a “cryptoperiod” well-defined?  How is it interoperable.  I wasn’t able to locate the relevant guidance in [KEY-MANAGEMENT] beyond statements of having a cryptoperiod.  Additionally, since [KEY-MANAGEMENT] is informative, the guidance for it can’t come from this document.

# Internet AD comments for draft-ietf-scitt-architecture-20
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S3

* I can't help but feel that "Transparency Statement" is a slightly better
  term than the somewhat-generic-sounding "Transparent Statement", but
  I'm guessing this is well past the stage at which terminology can be
  changed.

  Just an observation.

### S9.4.2

* What should an Issuer or Transparency Service do when a key is
  compromised beyond "communicate"?

  Should it, for example, establish new credentials and replay all
  signing operations with the new key(s)?

## Nits

### S2.1

* "Taking the type and structure of all statements about digital and
   products into account might not be possible."

   s/digital and products/digital products/ I think improves readability.