Re: [SCITT] [EXTERNAL] RE: SCITT Architecture document

[Steve Lasker <[e-mail]>]

Thanks, Roy,
A few PRs and questions on the items below:

1.  The introduction discusses distributed, ...  This word should be deleted.
Tracked at: https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/pull/230
2. Removal of Feeds
                While I could see how feeds could enable federation, or publishing of info for a specific artifact, feeds add value unto themselves as a way to get the related statements to an artifact (subject), or getting all statements from an issuer.
3. ...receipts don't expire...
Tracked at: https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/232
                We need a proposal for how to address this
5. In section 4.1.1.2<https://www.ietf.org/archive/id/draft-ietf-scitt-architecture-06.html#name-auditability-of-registratio> it alludes that an auditor can mine the log to authenticate and retrieve the transparent statement. ...
                Tracked at: https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/pull/233
6. By and large the generic aspect of the document is there but we missed one sentence: "Signed Statements and Artifacts associated  with a digital artifact."
                It wasn't clear where you're suggesting this get added or edited. The only place I saw "software package" was section 4.1.4: https://ietf-wg-scitt.github.io/draft-ietf-scitt-architecture/draft-ietf-scitt-architecture.html#section-4.1.4
                Can you provide a specific recommendation?


From: SCITT <[e-mail]> On Behalf Of Roy Williams (E+P)
Sent: Wednesday, March 27, 2024 3:29 PM
To: Richard Brooks <[e-mail]>; [e-mail]
Cc: Sylvan Clebsch <[e-mail]>; Cedric Fournet <[e-mail]>; Antoine Delignat-Lavaud <[e-mail]>
Subject: Re: [SCITT] [EXTERNAL] RE: SCITT Architecture document

That is acceptable to me.

From: Dick Brooks <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, March 27, 2024 3:28 PM
To: Roy Williams (E+P) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Sylvan Clebsch <[e-mail]<mailto:[e-mail]>>; Cedric Fournet <[e-mail]<mailto:[e-mail]>>; Antoine Delignat-Lavaud <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] RE: [SCITT] SCITT Architecture document

Roy,

Would "software package" be replaced with something more generic, like "digital artifact"?

Thanks,

Dick Brooks
[cid:image001.png@01DA8CE4.08D219F0]  [cid:image002.png@01DA8CE4.08D219F0]
Active Member of the CISA Critical Manufacturing Sector,
Sector Coordinating Council - A Public-Private Partnership

Never trust software, always verify and report!<https://reliableenergyanalytics.com/products> (tm)
http://www.reliableenergyanalytics.com<http://www.reliableenergyanalytics.com/>
Email: [e-mail]<mailto:[e-mail]>
Tel: [phone]


From: SCITT <[e-mail]<mailto:[e-mail]>> On Behalf Of Roy Williams (E+P)
Sent: Wednesday, March 27, 2024 6:23 PM
To: [e-mail]<mailto:[e-mail]>
Cc: Sylvan Clebsch <[e-mail]<mailto:[e-mail]>>; Cedric Fournet <[e-mail]<mailto:[e-mail]>>; Antoine Delignat-Lavaud <[e-mail]<mailto:[e-mail]>>
Subject: [SCITT] SCITT Architecture document

By and large the document is at a point where it can be called on for final reading.  There are some nits or issues that we would like to see done to tighten it up.


  1.  The introduction discusses distributed, but there is no real discussion of how or what that means and it leads readers to set an expectation that is incorrect.  This word should be deleted.
  2.  Removal of the Feeds definition.  This was in the original version, and we have bounced all over the place during the last year to formulate a solution to a problem with Federation.  We have decided collectively to park that and thus the use of feeds is gone.  In a future overarching product or charter it could come back.
  3.  There is a bit of a misunderstanding generated by stating that receipts don't expire, which later on is a line that requests for a refreshed receipt can be supported.  The logical receipt is intended to never expire and based on the protected content in the ledger's log a new receipt can be generated at any time.   This gives us an avenue to bridge a world from today to post quantum cryptography based counter signatures that is important.  We need to clear up these two points.
  4.  What goes into the append only log can vary from implementation to implementation.  It may be that one implementation records the hash of the signed statement, plus evidence of how we proved that it was valid at the time of acceptance (things like records of OCSP response, or CRL lookups).  Another implementation may simply store the signed statement.  This from a generic point of view means that given access to the signed statements you can prove that it is on the append only log always.
  5.  In section 4.1.1.2 it alludes that an auditor can mine the log to authenticate and retrieve the transparent statement.  Based on the last statement this has two problems.  The first it assumes that the signed statement is kept and that it can generate a new receipt (see 3) and produce a transparent statement.  If it could this would be equivalent to the original in intent but not binary equal.   The original receipt (or last created receipt from a refresh) is not required (or intended) to be kept in the ledger.  Generically then this is impossible and may be where we would leverage consistency proofs in a later version.

  1.  By and large the generic aspect of the document is there but we missed one sentence: "Signed Statements and Artifacts associated  with a software package." We would suggest removing the "software package".