Markdown Version | Session Recording

Session Date/Time: 12 Jun 2023 15:00

SCITT

Summary

The SCITT working group met to discuss the challenging topic of Registration Policies, a key component of the SCITT architecture. The discussion focused on finding a balance between defining a foundational, minimal set of requirements for registration policies to enable initial implementation and deployment, while also acknowledging the need to accommodate future complexity regarding issuer identity, trust anchors, and application-specific payload requirements. Additional updates were provided on hackathon progress and discussions around election security.

Key Discussion Points

• Agenda Bashing & Updates:

  • The primary agenda item was Registration Policies.
  • Ray mentioned working on endorsement related to election assistance and an air-gap protocol blended with TLS, stating it wasn't yet ready for discussion but would share a submission to the mailing list.
  • John provided an update on his hackathon action item, noting a usable implementation of the end-to-end receipt process in a GitHub branch for the public SCITT community working group, including the Microsoft provided emulator.
  • These additional topics (election security, hackathon) were added to the meeting notes for future consideration.

• Registration Policies (Core Discussion):

  • Initial Framing: Discussion began with acknowledging the complexity of registration policies and seeking a minimal viable version for the architecture document.
  • Gateway Function and Trust Anchors (Hank & John):
    • Hank suggested focusing on a "Gateway function" that limits issuers to the transparency service, primarily via "trusted income stories" (trust anchors).
    • John agreed that the easiest way is to gatekeep the registration of a signed statement using identity relationships. He noted flexibility is needed (e.g., IDP certificates for OIDC, device certificates for machine use cases).
    • John expressed caution against formally specifying identities (e.g., DID web/URN) or allowing registration policies to have semantic understanding of the payload, as these add unnecessary complexity for an initial spec.
  • Issuer Identity and Key Verification (Alex & Ory):
    • Alex clarified his understanding of "trust anchors" as public keys/certificates used by the transparency service to verify signed statements.
    • Ory recapped 116 discussions, highlighting the complexity of dependencies between envelope formats and reflecting policies in transparent statements via identifiers. He emphasized that verifying signed statements requires discovering keys authoritative for issuers, and verifiers will need their own ways to do this, meaning issuer identity must be discussed. Ory suggested that specific header parameters for cross-referencing policies were discussed at 116.
  • High-Level Definition vs. Implementation Details (Yogish):
    • Yogish advocated for keeping registration policy details at a high level in the architecture document, avoiding specifics that tie it to implementation. He suggested defining what the policy should do (e.g., unambiguously identify issuers via known trust anchors) rather than how.
  • SCITT as a TLS Proxy Agent (Ray):
    • Ray proposed viewing the SCITT service as a proxy agent for one side of a TLS connection, recording identity proofs (certificates) that would have been provided during a TLS handshake. This approach could memorialize these proofs, enabling future verification, and was helpful for air-gapped scenarios.
  • Future-Proofing and Evolving Trust (Roy):
    • Roy emphasized the need to future-proof for evolving identity providers (post-quantum, DID mechanisms) and security postures (CVEs, VEX, S-BOMs). He argued that the policy accepted at the time a receipt was issued needs to be known, as it represents the "policy bar" that was passed, rather than just raw information.
  • Hank's Four Decision Points for Progress: Hank summarized the immediate decisions needed to progress:
    1. Agreement that a key list (or "justification path" / certificate chain equivalent) is required to validate issuer identities.
    2. How to represent that list of public keys (trust anchors).
    3. Where to store it and how to find it (acknowledging concerns that a simple "feed" might not be sufficient).
    4. How to point at it from a receipt (representation of the identifier for lookup/resolution).
  • Concerns about Complexity and Relying Parties (Neil):
    • Neil expressed nervousness about adding too much complexity to SCITT. He stressed that relying parties ultimately make trust decisions. He questioned if merely restricting issuers via trust anchors is sufficient, given the risk of issuer compromise over time. He mentioned TUF (The Update Framework) as a robust, albeit complex, solution for compromise and key rotation, suggesting SCITT could acknowledge such external frameworks rather than trying to re-specify their functionality internally.
  • Authentication vs. Signing Identity (Yogish & Roy):
    • Yogish questioned whether the key used to sign a statement must be strictly correlated with the identity used to register with the transparency service (e.g., an authenticated connection identity).
    • Roy clarified that the signature on the statement itself is what primarily matters, not the transport mechanism or the identity of the authenticated connection used to submit it. The registration policy dictates what identities are accepted as valid signers.
  • Payload Focus vs. Superstructure (Charlie):
    • Charlie argued that for scenarios involving known parties or physical devices (e.g., medical devices), the "notary" metaphor and extensive policy superstructure might be less relevant. He advocated for spending more time on the payload itself—how to store and manipulate data structures like S-BOMs, supplier characteristics, countries of origin, and quality tracking—which currently receive less attention.
  • Runtime Policy Checking (Ori):
    • Ori noted that policy functionality shouldn't be entirely removed. Standardizing what policies were applied could facilitate faster runtime checks, allowing relying parties to check a subsection of policies rather than re-evaluating the whole. He offered to elaborate on this on the mailing list.
  • Rats Model for Policy Verification (Ray):
    • Ray suggested modeling registration policy verification after the RATS (Remote Attestation Procedures) approach, where a "registration policy verifier" could pre-process or review statements before they enter the SCITT machine, deferring specific implementation details to this verifier mechanism.

Decisions and Action Items

• Decision: General agreement to strive for a high-level definition of registration policies in the initial architecture document, focusing on what they achieve (e.g., unambiguous issuer identification and validation using trust anchors) rather than overly prescriptive how. Specific details on how to link policies to transparent statements or complex payload-aware policies will be considered for future extensions or as implementation-specific choices.
• Action Item: WG chairs/contributors to take Hank's four decision points (key list requirement, representation, storage/discovery, identifier representation) and propose concrete text for the architecture document, balancing simplicity with future extensibility.
• Action Item: Roy, Ray, and Charlie (and Alex/Ori if interested) to have an offline discussion to clarify their specific viewpoints and use cases regarding registration policies, S-BOMs, and the broader context of trust and policy in SCITT, and then summarize their findings in a thread on the SCITT mailing list.
• Action Item: John to share links to his end-to-end receipt process implementation branch on GitHub.
• Action Item: Ray to share his submission regarding election assistance and air-gap protocols on the mailing list.
• Action Item: Ori to elaborate on the mailing list how standardizing "what" policies were applied could enable faster runtime checks without complete re-evaluation.

Next Steps

• Further refinement of the registration policy section in the architecture document based on the discussion, aiming for a clear, concise, and extensible definition.
• Offline discussions among interested parties regarding specific policy scenarios and their implications for SCITT.
• Continue preparing for the upcoming hackathon, leveraging John's implementation.