Session Date/Time: 13 Mar 2023 16:00

SCITT

Summary

This meeting focused on the extensive overhaul of the SCITT Architecture document, particularly around terminology consolidation and its readiness for IETF 116 submission. Key discussions revolved around standardizing terms like "claims," "statement," "assertion," and deciding on "log" versus "ledger" for the core append-only data structure. The group also discussed the relationship between SCITT's Receipt ID and more generic COSE Merkle tree proofs, as well as the necessity of a unified signature method for global authenticity at the SCITT layer versus allowing diverse methods in the payload. The main outcome was the decision to submit the current architecture and use case documents to IETF 116, acknowledging several open terminology and technical discussions for future work.

Key Discussion Points

Architecture Document Update: The draft-ietf-scitt-architecture document underwent a significant overhaul, with much of the work done by Hank and Steve, focusing on terminology consolidation. The updated document is considered ready for submission for IETF 116.
Terminology Consolidation:
- Claims, Statement, Assertion: A previous contentious discussion regarding these terms was resolved, and the merged PR is considered to represent consensus. Changes were primarily reflected in Figure 1, with basic terminology in boxes and solutions related to COSE/signing procedures in arrows.
- Log vs. Ledger vs. Registry:
  - The discussion indicated a strong preference for the most agnostic term: "append-only log" to describe the repository/retention system.
  - "Ledger" is seen as having connotations tied to blockchain, which the WG wishes to avoid.
  - "Registry" has IETF-specific connotations that are also to be avoided in this context.
  - While "append-only log" is the favored candidate, this change is not yet fully resolved or incorporated into the current draft, and will be addressed in future work.
- Transparency Service Name: The term "Transparency Service" for the overall SCITT system/instance was acknowledged as potentially problematic due to nuances around transparency, but it was agreed to maintain consistency with this term in the current document for now.
Receipt ID and COSE Merkle Tree Proofs:
- SCITT's Receipt ID concept relates to a more global concept of COSE Merkle tree proofs.
- A decision was made to split these efforts: SCITT will continue with its specific Receipt ID for providing metadata with counter-signing proofs, while more generic Merkle tree definitions will be explored in parallel within the COSE working group.
- Consolidation between these two tracks is expected between IETF 116 and IETF 117. The IETF 116 submission will not refer to the not-yet-accepted COSE Merkle tree specification to avoid confusion.
Signature Method Specifications:
- A significant discussion point was the extent to which SCITT should specify a signature method for its core authenticity layer.
- The argument was made that a single, standardized signature method (e.g., COSE) is essential for global interoperability, fast authentication resolution, and to avoid burdening small devices with multiple cryptographic stacks.
- However, it was clarified that domain-specific signatures can be nested within the SCITT payload, which can then be processed via "non-opaque statements" that describe how to handle these nested signatures.
- This topic was identified as a "pain point" that requires dedicated discussion time at a future meeting (Yokohama).
Append-Only Log Implementation Specificity:
- The level of detail for specifying append-only log implementations was discussed, with mentions of solutions like AWS QLDB.
- It was noted that referencing specific named algorithms or branded technologies would require vetting through the Crypto Forum Research Group (CFRG) process, which adds time and complexity.
- The current approach leans towards defining the behavior (e.g., "must not delete") rather than prescribing specific implementations or data structures, allowing flexibility while preserving the core append-only characteristic.
Media Types for Payloads: The suggestion was made to utilize standard MIME types to communicate information about payload formats and signatures, as this could complement SCITT's authentication mechanism and provide flexibility for diverse content. This was viewed positively as future work.
Linking to National Cybersecurity Strategy in Use Cases:
- A suggestion was made to include a link to the U.S. National Cybersecurity Strategy in the Use Case document, citing its relevance to supply chain transparency and trustworthiness.
- The general sense among participants was to avoid including jurisdiction-specific references in IETF documents, as this could narrow the scope or imply endorsement of one nation's approach over others (e.g., EU solutions).
- While the relevance to SCITT's goals was acknowledged, the preference was to either include broader, international examples or address such specific strategies in separate, extended use case documents if they become highly relevant.

Decisions and Action Items

Decision: The draft-ietf-scitt-architecture and draft-ietf-scitt-use-cases documents will be submitted as Working Group items today for formal consideration at IETF 116.
Decision: Terminology changes regarding "log" over "ledger" are not included in the current submission but will be addressed in future work. The current document is considered in good enough shape for submission.
Decision: The group will continue to split development of SCITT-specific Receipt IDs from generic COSE Merkle tree proofs, with consolidation planned post-IETF 116.
Action Item: The critical discussion around crypto agility and the requirement for a specific signature technology at the SCITT layer will be added as an agenda item for the IETF 117 meeting in Yokohama.
Action Item: All participants are encouraged to read the updated documents (architecture and use cases) before IETF 116 begins.

Next Steps

Continue Discussions: Further discussions will be held on the nuances of terminology, especially regarding "append-only log" implementation details and the naming of the "Transparency Service."
IETF 116 Engagement: Prepare for potential feedback and discussions arising from the submission of the architecture and use case documents at IETF 116.
Yokohama Agenda: Formalize the agenda item for IETF 117 (Yokohama) regarding the core signature technology and crypto agility.
Use Case Document Refinement: Consider how to broaden the scope of examples in the use case document to include international legislative and strategic initiatives, avoiding jurisdiction-specific references.
Regular Meetings: The weekly Monday meetings will continue to facilitate ongoing discussions and progress on open issues.