Re: [SCITT] Call for adoption - SCITT Architecture

[Michael Richardson <[e-mail]>]

I have read:

> https://datatracker.ietf.org/doc/html/draft-birkholz-scitt-architecture-02

and I think that it is suitable for WG adoption.

Some comments:

1) "TS" seems to be have been defined only in the Abstract. I learnt what it
was by seeing it in the table of contents.

2) I hate the word "Transparent" here.  THe claim is not transparent.
If it were, you coudn't see it.  It's the container that is transparent,
allowing one to see the claim.  The term became wrongly idiomatic to
(legal) "process", which is to say a legal process was transparent if, while
looking at the results, you could see through the bureaucracy around the
process (the bureaucracy was transparent) to see what was inside.
(Kafka wrote about a bureaucracy which was not transparent)
Certificate Transparency, in my opinion, borders to being silly as well, but
it doesn't claim the certificates are transparent, rather the process of
issuing them is.

I suggest that we don't want to talk about Transparent Claims, but rather, we
want to tralk about Public Claims, or Visible Claims or something.

section 2.2 then says:
  "A supply chain that maintains a transparent record of the successive"

Again, I want a visible record.

2.3, about Cold Chains, seems unusually specific.  It seems like we are
unduly concerned about sea food, but not for instance, concerned with keeping
my french fries from suffering freezer burn. (Defrosting and re-freezing)
I think that this section needs to be re-written as more of an examplar.

I see that section 4 tries to justify the term, and 5.2 tries some more.
Having read those sections, I'm more than ever convinced that it's the wrong
term.

In section 5,2 _Practical Byzantine Fault Tolerance (pBFT [PBFT])_ is
suggested but I'm unclear how/if there is any requirement being created here.
I get the impression that this is an internal/functional requirement and has
no interoperability impact.

}   TS implementations SHOULD make their full registration
}   policy public and auditable, e.g. by recording stateful policy inputs
}   at evaluation time in the registry to ensure that policy can be
}   independently validated later.

So, specifially, a TS should not be transparent (invisible) about it's
policy, but must be explicit about it.

} 5.2.3.  Registry Security Requirements
tries to say that blockchain is not required while not actually saying so,
because there are still people in this group who want to boil the ocean.

}6.3.  Standard registration policies
}
}      *Editor's note*
}
}      The technical design for signalling and verifying registration
}      policies is a work in progress.  We expect that once the formats
}      and semantics of the registration policy headers are finalized,
}      standardized policies may be moved to a separate draft.  For now,
}      we inline some significant policies to illustrate the most common
}      use cases.

is it time to split this off into a new document as part of the adoption
process?  Or is there another plan to do this at some future time, and if so,
could that be detailed?

I think that some of the Security Considerations could go into the
Introduction, or earlier text.   Perhaps repeated there.
The SC is well done.

for instance:
   Due to the operational challenge of maintaining a globally consistent
   append-only Registry, some TS may provide limited support for
   historical queries on the Claims they have registered, and accept the
   risk of being blamed for inconsistent Registration or Issuer
   equivocation.

should probably mentioned earlier.

And also:
}   The TS is trusted with the confidentiality of the claims presented
}   for registration.  Some TS may publish every claim in their logs, to
}   facilitate their dissemination and auditing.  Others may just return
}   receipts to the client that present claims for registration, and
}   disclose the ledger only to auditors trusted with the confidentiality
}   of its contents.

i.e. some transparency services are not transparent.
It's really really really not the right term.





--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide