We should take whatever action is appropriate to move SCITT from drawing board to implementation.
A SCITT software product "Trust Registry" is vitally important now, especially given the upheaval with CVE reporting that we see occurring. Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! ™ Risk always exists, but trust must be earned and awarded.™ https://businesscyberguardian.com/ Email: [email protected] Tel: +1 978-696-1788 -----Original Message----- From: Henk Birkholz <[email protected]> Sent: Monday, May 5, 2025 9:48 AM To: Jon Geater <[email protected]>; Thomas Fossati <[email protected]>; Roman Danyliw <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: [SCITT] Re: Roman Danyliw's Discuss on draft-ietf-cose-tsa-tst-header-parameter-05: (with DISCUSS and COMMENT) Hi all, assuming that re-chartering COSE could potentially cascade into rechartering a 6 year old charter instead of extending deliverables ("just" updating deliverables/work items vs. extending the narrow scope), I assume it boils down to "what is the most feasible+fastest route" for adopted COSE I-D(s) that now will hit the same road block. Looking back on past rechartering actions, I'd assume that moving I-Ds to appropriate WGs (most of this work is cross-wg in the first place) could be faster than blocking on a rechartering. Thomas brought up AD sponsoring, but I am not very familiar with that process, tbh. Given that the WGLC results and complementary reviews are available, this could also provide an efficient alternative route? Jon asked about TST-TSA scope and application ("is it scitt?"). TST-TSA parameters are directly used by RATS for freshness in time-based remote attestation and directly used by SCITT for registering signed statements at a Transparency Service. Both seem fine to me, but RATS seems to be the more "crowded" WG. TL;DR live experience shows that waiting for rechartering of a wg might result in the longest detour. WDYT? Viele Grüße, Henk p.s. list of I-Ds that (will) hit the road block potentially: * In IESG Evaluation, telechat slot on Thursday: https://datatracker.ietf.org/doc/draft-ietf-cose-tsa-tst-header-parameter/ * In IETF Last Call: https://datatracker.ietf.org/doc/draft-ietf-cose-merkle-tree-proofs/ * In WGLC: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-envelope/ On 05.05.25 14:50, Jon Geater wrote: >> Specifically, I am referring to: >> * COSE Receipts >> * COSE Hash Envelope >> * COSE Header parameter for RFC 3161 Time-Stamp Tokens > >> […] > >> Regarding redispatching, SCITT could serve as a good home for all >> three. SCITT folks: can you confirm? > > Although I have been watching some of the conversation I’m not > terribly familiar with the TST header one, but the other two > certainly: they are the basis of SCITT’s ability to service software > supply chain artifacts, particularly very large or remote ones. > > From a raw architecture point of view I liked them being in COSE, > since they’re also useful for non-SCITT uses of COSE/CBOR, but the > SCITT WG needed that work done and so it seems very plausible to move > them across, ADs willing. > > I’ll read up on TST. > > Jon > > On 05/05/2025, 14:29, "Thomas Fossati" <[email protected]> wrote: > > [ CC -= IESG; CC += SCITT ] > > On Fri, 2 May 2025 at 17:33, Roman Danyliw via Datatracker > <[email protected]> wrote: >> --------------------------------------------------------------------- >> - >> DISCUSS: >> --------------------------------------------------------------------- >> - >> >> For the responsible AD and WG chairs -- this document is not in scope >> for the current WG charter. My understanding of its substance is >> that it defines two, new COSE attributes. The approved -03 charter >> explicitly says: >> >> “The WG will produce documents for new attributes only if they are in >> the list of deliverables below. A re-charter will be required to expand that >> list. >> The WG is expected as part of normal processing to review and comment >> on attributes that are not in charter but are of general public interest.” >> >> There is no subsequent reference to work about specifying timestamp >> related attributes in the work items section of the charter (or any other >> place). > > Thanks, Roman, for pointing this out. > > At a glance, it seems that three of seven (i.e., ~40%) of the > currently adopted documents are out of scope. > > Specifically, I am referring to: > * COSE Receipts > * COSE Hash Envelope > * COSE Header parameter for RFC 3161 Time-Stamp Tokens > > All three are quite advanced (in particular, “TST header parameters” > is with the IESG, and "Receipts" is in WGLC). > > Possible ways out include: > * Rechartering to put them in scope, > * Re-dispatching to other WGs, or > * Seeking AD sponsorship. > > Given that the WG has already invested considerable effort in the > documents, a (quick) retrospective rechartering does not seem > unnatural to me. > (Besides, while I tend to prefer charters with a narrow scope, I > believe the current COSE charter is a bit *too* narrow, considering > the breadth of the problem space?) > > Regarding redispatching, SCITT could serve as a good home for all > three. SCITT folks: can you confirm? > > AD sponsorship seems the least compelling route, but I am happy to be > convinced otherwise. > > Any thoughts or (possibly brilliant) ideas? :-) > > cheers! > > -- > SCITT mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- SCITT mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
