Markdown Version | Session Recording
Session Date/Time: 16 Jan 2023 16:00
SCITT
Summary
The SCITT Working Group met to discuss ongoing work items, focusing on the architecture document's open issues, the progression of the use cases document, and the persistent challenge of terminology alignment, especially between Rats and SCITT. A new SCITT Community was announced, aiming to complement the WG's standardization efforts with focus on advocacy, testing, and interoperability. The upcoming IETF 116 session request was also noted, with a goal to advance documents by the March 13th cutoff.
Key Discussion Points
- Meeting Logistics: The meeting started with acknowledgments of the MLK Day holiday impacting attendance. Kieran volunteered to take meeting minutes.
- Initial Agenda: The chairs outlined the agenda: threat model, use cases, architecture document open issues/pull requests, and terminology.
- IETF 116 Session Request: The chairs confirmed a session request for IETF 116 has been submitted. Preparation for presentations and document readiness for the March 13th submission cutoff date is ongoing.
- Architecture Document Issues and Pull Requests:
- Issue 28 (Replace TS with SCITT): This issue was deemed outdated and resolved, as the group is now using "transparency services."
- Issue 42 (Compact/Artifact): The term "artifact" is overloaded, especially across different supply chains (software vs. physical). This topic was identified as needing a dedicated session, and it will be lumped under the broader terminology discussion.
- Issue 37 (Terminology State Terminology): This issue is central to the ongoing terminology challenges, encompassing overlaps between Rats and SCITT.
- Issue 34 (Converge Claim Statement): A proposal to converge "claim" and "statement" was discussed. The current leaning is to define "statement," "signed statement," and "transparency statement" first, potentially mapping back to "claim" later if appropriate.
- Issue 29 (Definitions and terms change statement to evidence): This was identified as an older, likely outdated issue from before the first working group meeting. It highlighted conflicts between the use of "evidence" in Rats (signed set of claims) and its potential use in SCITT (opaque payload from supply chain). It was considered superseded by other terminology discussions.
- Rats vs. SCITT Terminology (Claim, Statement, Evidence, Artifact):
- Ray observed that "claim" in Rats often refers to an upstream assertion by a tester device, while in SCITT it could be a downstream assertion by an entity submitting software. He suggested discriminating them perhaps with adjectives.
- Discussion ensued on how to manage terminology conflicts given existing terms in other domains (e.g., US government "evidence," "build evidence," "artifact" for caching).
- There was a sense that while "gorillas" (established external terminology) cannot be moved, the WG can qualify terms, make users aware of conflicts, and strive for comprehensive and intuitive definitions within the IETF's control.
- Use Cases Document:
- The importance of establishing clear use cases to define SCITT's problem space, boundaries, and scope was reiterated. Several participants indicated that progress on terminology hinges on clarifying use cases.
- The target for IETF 116 is to have all known use cases presented in a comparable, uniform style and structure, rather than necessarily a final, limited set of five foundational use cases.
- Ray's Election Use Case: Ray presented his document (shared via chat) on securing valid election images.
- Core Problem: End-to-end security of valid images from voting machines/scanners, posting secure data into SCITT.
- Data Volume: Involves very large files (5-10 GB each), with millions of images across jurisdictions, making it incompatible with putting all data directly into a SCITT payload. Hashes would be posted to SCITT, with actual data on separate posting services.
- Voting Machine Architecture: Prefers a trusted core and split between document scanner and ballot-aware tabulator, ideally with Hardware Security Modules.
- Air-Gapped Environment: Election systems are typically air-gapped, with data physically carried on flash drives or limited modem transmission. SCITT interactions would occur only after data is aggregated and brought to a connected system. This poses a requirement for SCITT to handle eventually consistent or delayed submissions of security information.
- Public Key Claims: Ray highlighted a need to resolve how public keys from devices in an air-gapped scenario are securely claimed or managed (e.g., by an Election Management System database). Ray was advised to look at the confidential compute framework and drone community's work on long-lived device identities.
- New SCITT Community Announcement: Kieran announced the formation of a new, complementary SCITT Community.
- Purpose: Focus on advocacy, outreach, testing, interoperability of implementations, prototyping, and tooling.
- Relationship to WG: Facilitates adoption and early prototypes while the WG focuses on specification development (use cases, architecture, RFCs).
- Participation: Open to the public; an email with links and kickoff meeting details (this Thursday) will be sent to the WG list.
Decisions and Action Items
- Decision: Close issue #28 (Replace TS with SCITT) as it is outdated.
- Action Item: Yogesh, Cedric, and Hank to drive the terminology discussion on the mailing list, specifically addressing issues #37, #34, #29, and #42.
- Action Item: Hank to schedule an offline meeting/case study discussion with Joshua regarding the six-door case studies and their representation in the SCITT use cases.
- Action Item: Ray to refine and explicitly list the specific SCITT requirements identified from his election use case within his document.
- Action Item: The architecture document editors to meet and propose a resolution for the "claim" vs. "statement" and other terminology issues for broader WG discussion.
- Action Item: Kieran to send out an email to the SCITT WG mailing list detailing the new SCITT Community, including links and information about its kickoff meeting.
Next Steps
- Continue active discussions on terminology on the mailing list.
- Progress the use case document, aiming for all known use cases to be in a uniform style and structure by the IETF 116 submission cutoff (March 13th).
- Zach (or Joshua) to present the six-door case studies at the next WG meeting.
- The architecture document editors will work on resolving outstanding issues and terminology definitions.
- Further review and discussion of Ray's election use case and its derived requirements.