Markdown Version | Session Recording

Session Date/Time: 30 Jan 2023 16:00

SCITT

Summary

The SCITT Working Group met to discuss updates to the use case document, with a significant portion of the session dedicated to clarifying roles and terminology. The primary focus was on the relationship between suppliers, signers (referred to as "signing authority"), and distributors, and the verifiability of trust relationships in software supply chains. Extensive debate occurred regarding the term "signing authority," its implications for delegation, policy, and the need for clear definitions within the use cases.

Key Discussion Points

• Meeting Logistics: Initial challenges with finding the correct meeting link were noted.
• Use Case Document Review:
  • Yogesh, Hank, and Dick had updated the use case document, particularly simplifying and reverting some aspects, focusing on four key use cases.
  • An open item related to the emphasis on the "distributor" role, particularly concerning the hard link between supplier and distributor, was highlighted.
  • The document aims to cover different aspects of software distribution systems and highlight various problems, potentially leading to document growth.
• Role Definitions and "Signing Authority" Terminology:
  • Initial Framing: The first use case proposed three roles: package supplier, signing authority, and distribution entity.
  • Distributor Clarification (Dick): Examples like systems integrators (e.g., Price Cooper's Waterhouse) were given to illustrate scenarios where a distributor provides software from multiple suppliers, each with their own signer, without being the signer themselves. While App Stores might sign, other cases do not combine distributor and signer.
  • Trust Relationship (Dick): The core idea is a trust relationship established between the supplier and the authorized signer, with distributors being separate.
  • "Signing Authority" Concerns (Neil):
    • Expressed confusion over the term "signing authority," questioning how a verifying party would know which entities are authorized to sign for a particular supplier, especially if a supplier uses different signers for different distributors (a many-to-many relationship concern).
    • Asked why a supplier cannot simply sign for themselves, highlighting the complexity of delegation and policy languages.
  • Third-Party Endorsements (Michael): Explained that the U.S. Executive Order drives the need for third parties (auditors, certification bodies) to provide endorsements beyond self-claims from producers. This differentiates the producer's role (producing evidence) from an auditor's role (evaluating evidence and making claims about trust).
  • Supplier's Role in Evidence (Charlie): Emphasized that suppliers should have full authority to provide and sign their own evidence about compliance with standards, viewing "signing authority" and "auditor" roles as somewhat fuzzy.
  • Roles vs. Entities (Dick): Clarified that "supplier," "signer," and "distributor" are roles, and a single entity (e.g., Microsoft) can fulfill all three roles simultaneously.
  • Reframing "Signing" (Ray):
    • Argued against "signing for someone else" and the concept of an "authorized signing authority." An entity can only sign for itself. Delegation would involve a separate statement from the delegating party.
    • Suggested the term "approving" or "stamping approval" if an entity reviews various signatures and attestations (supplier, test house, fips compliance, etc.) before issuing its own approval.
  • Use Case vs. Solution (Hank): Apologized for the confusion caused by "signing authority," stressing that use cases describe problems or needs from a stakeholder perspective, not the architectural solution. Skit itself only allows entities to attest to what they say.
  • Empirical Case (Dick): Provided a real-world example of verifying "Oracle America" signing a JRE package supplied by "Oracle," highlighting the need for a mechanism to verify the trust relationship between the supplier and the signer, beyond just cryptographic validation.
  • Policy Language (Neil): Raised the need for use cases that describe a more general policy language to help verifiers understand and track chains of trust, especially for complex compliance requirements (e.g., FIPS, S-BOMs). This was acknowledged as a valuable, though potentially solution-oriented, discussion point.

Decisions and Action Items

• Review and Comment on Use Case PR: All participants, especially those who raised concerns (Neil, Zach, Joshua), are strongly encouraged to review the current use case document PR and provide specific comments or open new issues to address identified gaps and ambiguities.
• Mailing List Discussion: Further detailed discussion on the use case document, particularly regarding the contentious "signing authority" terminology and the clarification of roles, should continue on the SCITT mailing list.
• Update Use Case Document: The document text needs updates based on the detailed discussion to better clarify roles, relationships, and the intent behind various attestations.

Next Steps

• The WG will continue refining the use case document, focusing on clear definitions of roles and the nature of verifiable trust relationships.
• Participants should engage with the current PR for the use case document to provide concrete feedback.
• Future meetings will likely revisit these use cases, potentially moving towards architectural discussions once the problem space is sufficiently defined.