Markdown Version | Session Recording

Session Date/Time: 08 Jan 2024 16:00

SCITT

Summary

The SCITT Working Group discussed recent architectural updates, including dependency reordering and the status of the Cozy hash envelope. A significant portion of the meeting was dedicated to a detailed debate on refining the roles of "Verifier," "Relying Party," and "Auditor" to align with broader IETF and industry terminology, acknowledging the nuances with RATS. The group also revisited the challenge of including configuration and policy information within receipts, aiming for a lightweight "indicator of state" in the architecture while deferring specific formats. Finally, a substantial pull request modifying the document's introduction was highlighted for review.

Key Discussion Points

• Architecture and Dependency Tracking (PR 148, 149):

  • PR 148 introduced a dependency diagram to track necessary items for spec completion.
  • PR 149 formally reversed the dependency ordering, making Scrappy an implementation dependent on the core architecture, rather than the architecture referencing Scrappy. This clarifies that Scrappy is an application of the architecture.
  • The architecture remains dependent on Merkel tree proofs and the Cozy hash envelope.
  • Cozy Hash Envelope Discussion: There was clarification on whether the Cozy hash envelope is a blocking dependency for the architecture. Ori suggested that if COSE Sign1s are the only COSE object type supported by SCITT, then the hash envelope (for signing by reference) would be a way to achieve arbitrary content signing within that constraint. However, if it requires a new CDDL structure outside of COSE Sign1, it would block architecture. Ori believes it can be a separate document and not necessarily a dependency for either architecture or Scrappy, provided it fits within existing COSE Sign1 structures. A sense of those present indicated that clarifying the Scrappy split and adoption would bring more clarity here.

• Verifier, Relying Party, and Auditor Terminology:

  • AJ proposed aligning SCITT roles (Verifier, Relying Party, potentially dropping "Auditor") with existing IETF (e.g., OAuth) and non-IETF specifications, particularly noting inconsistencies with RATS.
  • Ori supported this, viewing "Auditor" as confusing in a security processing context. He clarified that a Relying Party needs cryptographic assurance, distinguishing between those who perform verification themselves and those who rely on a trusted Verifier. He viewed an "Auditor" as always a Relying Party, interested in content, not just signature validity.
  • Roy strongly argued for retaining "Auditor," citing its established role in government and business for software supply chains, particularly regarding data access, privacy, and making specific claims beyond mere cryptographic verification. He cautioned against a "bottom-up" terminology definition that would conflict with external governmental requirements.
  • Hank highlighted the fundamental differences in confidence levels and "evidence" between SCITT and RATS, suggesting that a SCITT "Verifier" and a RATS "Verifier" perform very different functions despite both checking signatures. He questioned if a SCITT Auditor could be a RATS Verifier, concluding it's more akin to a RATS Relying Party that consumes attestation results.
  • Grant suggested the "Verifier" role could be analogous to a "notary" that checks proof of possession of a private key, providing documentation for later reliance by a Relying Party.
  • AJ reiterated that "Auditor" is vague in a software/protocol context and can be a superset of many unrelated roles in government, making it unsuitable for protocol definition.
  • A strong sense of those present indicated a desire to avoid using terms that have different meanings in closely related specifications. It was suggested that the architecture should use generic terms (e.g., building blocks) and provide examples of how roles like "Auditor" could be built using those blocks, rather than defining "Auditor" as a core architectural role.

• Configuration and Policy Receipt Inclusion:

  • Steve presented the problem: how to capture the active registration policy and configuration within a receipt so that evaluators understand the transparency service's state when the receipt was issued. This is crucial for long-term evaluation and auditing of receipts.
  • Ori's view: Specific content types for configuration or registration policies do not belong in the architecture. Interoperability for references could be achieved if the architecture defined a mandatory-to-support identifier scheme for sign statements and receipts, but even that might lead to a difficult "one true identifier" debate. He suggested leaving implementation details out of the architecture.
  • Roy emphasized the practical need for an indicator within the receipt itself to signal changes in policy or configuration, avoiding the need to re-evaluate policies for every receipt. He argued against Scrappy solving this as it's a fundamental aspect of the receipt's validity, not just an API capability.
  • A sense of those present supported the concept of including some indicator of state in the receipt, but favored keeping it minimal in the architecture, deferring full definition of content types and formats to Scrappy or future versions (V2) to avoid rabbit holes. The architecture should only specify that the receipt refers to an "indicator of state."

• Introduction Changes (PR 143):

  • Th Goel submitted a substantial pull request (PR 143) to significantly strip down and reduce the architecture document's introduction.
  • The goal is to improve clarity, explain the connection to CT, and remove duplicated content that is detailed later in the document.
  • Due to its size, contributors were encouraged to review it carefully and provide feedback.

Decisions and Action Items

• Decision: PR 149, which reversed Scrappy's dependency on the architecture, has been adopted.
• Action Item: The WG chairs will initiate a discussion on the mailing list regarding the terminology for Verifier, Relying Party, and Auditor roles. The aim is to make an explicit decision on whether to align with existing specifications or intentionally use different terms to avoid ambiguity, focusing on using generic terms in the architecture.
• Action Item: Review and provide feedback on PR 143 (introduction changes) due to its significant scope. The chairs aim to merge this PR soon after feedback is incorporated.
• Action Item: Further refine the architecture's approach to including configuration/policy information in receipts. The current direction is to specify only a generic "indicator of state" within the receipt itself, deferring detailed format definitions to Scrappy or later versions to facilitate progress.

Next Steps

• Continue discussion on terminology (Verifier, Relying Party, Auditor) on the mailing list.
• Gather feedback on and merge PR 143 to simplify the document's introduction.
• Finalize the "indicator of state" concept for receipts within the architecture document.
• Progress the Scrappy split and adoption.