SCITT

Summary

The meeting's primary focus was a detailed discussion on registration policies, particularly the balance between preventing spam and ensuring transparency by allowing diverse, potentially distrustful, parties to make statements about artifacts. Due to low attendance (Juneteenth holiday), no consensus decisions were made on this topic. The working group decided to pivot the IETF 117 hackathon from interoperable registration policies to a use-case driven approach, with a strong inclination towards an FDA medical device cybersecurity use case involving a "Vendor Response File" (VRF).

Key Discussion Points

Registration Policies

Definition and Scope: Initial confusion existed regarding whether a registration policy applies to the log as a whole, specific products, or feeds. It was clarified that SCITT aims to allow identification and access control at the feed level, not to restrict who can comment on a product.
Spam vs. Transparency: A core tension was identified between preventing spam and denial-of-service attacks on a SCITT service and the desire to allow security researchers, transparency advocates, or other third parties to make legitimate (though potentially unwelcome by a vendor) observations about artifacts.
Feeds Structure: The concept of separate feeds for different issuers (e.g., an official vendor feed vs. a security researcher feed commenting on the same artifact) was proposed as a solution to balance control and transparency. This structure enables mutually distrustful parties to make observations.
Transparency Service Responsibility: There was a strong sense that the specific access control policies to prevent spam and vet submitters should be the responsibility of the transparency service operator, rather than being strictly defined in the SCITT standard. The standard should provide the necessary dimensions and mechanisms that can be leveraged.
Implementation Specificity: It was reiterated that robust access control mechanisms, while important for practical deployments, are implementation-specific and outside the direct scope of the SCITT core specification.
"Strict Model" Debate: A concern was raised that without a "strict model" where only authorized product owners can submit, SCITT could become a "spam magnet." While the standard should support such strict models, it was also argued that focusing solely on them might hinder the broader transparency goals.

IETF 117 Hackathon Aims

Pivot from Interoperable Registration Policies: Due to insufficient progress and the complexity of achieving interoperable registration policies at this stage, the working group agreed to shift the hackathon's focus.
Use-Case Driven Approach: The new aim is to demonstrate the usefulness of SCITT's building blocks through practical use cases.
FDA Medical Device Cybersecurity Use Case: Dick Brooks presented a detailed use case stemming from new FDA requirements (effective October 1st) for medical device manufacturers (MDMs) to submit SBOMs and related cybersecurity information.
- Vendor Response File (VRF): The proposed mechanism involves MDMs creating a digitally signed "Vendor Response File" (VRF) containing URLs and metadata for required disclosures (SBOMs, vulnerability reports, SDLC policies, commercial/support status, etc.).
- SCITT Integration: The VRF would be registered as a payload in a SCITT transparency service, which would issue a receipt/URL. MDMs could then provide this URL to the FDA, who would retrieve the VRF and subsequently download the referenced materials.
- Searchability and Scope: Discussion included the need for searchability within SCITT for VRFs (e.g., by vendor, product name) and how the VRF, while meeting official requirements, could also accommodate unmandated but relevant third-party observations or disclosures about product risks.

Decisions and Action Items

Decision: No consensus decisions on registration policies were made due to low attendance.
Decision: The IETF 117 hackathon focus will pivot from interoperable registration policies to a use-case driven demonstration of SCITT's usefulness.
Decision: The FDA medical device cybersecurity use case, utilizing a Vendor Response File (VRF), will be explored as a primary candidate for the IETF 117 hackathon.
Action Item: John (chair) will clarify the scope and definition of "feeds" within the SCITT architecture document to address current ambiguities.
Action Item: John (chair) will refine wording in the SCITT specification to articulate minimum requirements and expected outcomes, while avoiding over-specification of implementation-specific mechanisms for access control.
Action Item: Dick Brooks will coordinate with John regarding the FDA VRF use case for the hackathon and offered to contribute the VRF's XML schema to the IETF SCITT group.
Action Item: Roy to be included in upcoming discussions related to the FDA use case.

Next Steps

Continue discussions on registration policies, focusing on refining the terminology and scope of "feeds" in the SCITT architecture.
Actively plan for the IETF 117 hackathon, centering on the FDA medical device cybersecurity use case and the potential development of a generic Vendor Response File.
John and Dick will synchronize efforts on the VRF contribution and hackathon logistics.

Session Date/Time: 19 Jun 2023 15:00

SCITT

Summary

Key Discussion Points

Registration Policies

Definition and Scope: Initial confusion existed regarding whether a registration policy applies to the log as a whole, specific products, or feeds. It was clarified that SCITT aims to allow identification and access control at the feed level, not to restrict who can comment on a product.
Spam vs. Transparency: A core tension was identified between preventing spam and denial-of-service attacks on a SCITT service and the desire to allow security researchers, transparency advocates, or other third parties to make legitimate (though potentially unwelcome by a vendor) observations about artifacts.
Feeds Structure: The concept of separate feeds for different issuers (e.g., an official vendor feed vs. a security researcher feed commenting on the same artifact) was proposed as a solution to balance control and transparency. This structure enables mutually distrustful parties to make observations.
Transparency Service Responsibility: There was a strong sense that the specific access control policies to prevent spam and vet submitters should be the responsibility of the transparency service operator, rather than being strictly defined in the SCITT standard. The standard should provide the necessary dimensions and mechanisms that can be leveraged.
Implementation Specificity: It was reiterated that robust access control mechanisms, while important for practical deployments, are implementation-specific and outside the direct scope of the SCITT core specification.
"Strict Model" Debate: A concern was raised that without a "strict model" where only authorized product owners can submit, SCITT could become a "spam magnet." While the standard should support such strict models, it was also argued that focusing solely on them might hinder the broader transparency goals.

IETF 117 Hackathon Aims

Pivot from Interoperable Registration Policies: Due to insufficient progress and the complexity of achieving interoperable registration policies at this stage, the working group agreed to shift the hackathon's focus.
Use-Case Driven Approach: The new aim is to demonstrate the usefulness of SCITT's building blocks through practical use cases.
FDA Medical Device Cybersecurity Use Case: Dick Brooks presented a detailed use case stemming from new FDA requirements (effective October 1st) for medical device manufacturers (MDMs) to submit SBOMs and related cybersecurity information.
- Vendor Response File (VRF): The proposed mechanism involves MDMs creating a digitally signed "Vendor Response File" (VRF) containing URLs and metadata for required disclosures (SBOMs, vulnerability reports, SDLC policies, commercial/support status, etc.).
- SCITT Integration: The VRF would be registered as a payload in a SCITT transparency service, which would issue a receipt/URL. MDMs could then provide this URL to the FDA, who would retrieve the VRF and subsequently download the referenced materials.
- Searchability and Scope: Discussion included the need for searchability within SCITT for VRFs (e.g., by vendor, product name) and how the VRF, while meeting official requirements, could also accommodate unmandated but relevant third-party observations or disclosures about product risks.

Decisions and Action Items

Decision: No consensus decisions on registration policies were made due to low attendance.
Decision: The IETF 117 hackathon focus will pivot from interoperable registration policies to a use-case driven demonstration of SCITT's usefulness.
Decision: The FDA medical device cybersecurity use case, utilizing a Vendor Response File (VRF), will be explored as a primary candidate for the IETF 117 hackathon.
Action Item: John (chair) will clarify the scope and definition of "feeds" within the SCITT architecture document to address current ambiguities.
Action Item: John (chair) will refine wording in the SCITT specification to articulate minimum requirements and expected outcomes, while avoiding over-specification of implementation-specific mechanisms for access control.
Action Item: Dick Brooks will coordinate with John regarding the FDA VRF use case for the hackathon and offered to contribute the VRF's XML schema to the IETF SCITT group.
Action Item: Roy to be included in upcoming discussions related to the FDA use case.

Next Steps

Continue discussions on registration policies, focusing on refining the terminology and scope of "feeds" in the SCITT architecture.
Actively plan for the IETF 117 hackathon, centering on the FDA medical device cybersecurity use case and the potential development of a generic Vendor Response File.
John and Dick will synchronize efforts on the VRF contribution and hackathon logistics.

Session Date/Time: 19 Jun 2023 15:00

SCITT

Summary

Key Discussion Points

Registration Policies

Definition and Scope: Initial confusion existed regarding whether a registration policy applies to the log as a whole, specific products, or feeds. It was clarified that SCITT aims to allow identification and access control at the feed level, not to restrict who can comment on a product.
Spam vs. Transparency: A core tension was identified between preventing spam and denial-of-service attacks on a SCITT service and the desire to allow security researchers, transparency advocates, or other third parties to make legitimate (though potentially unwelcome by a vendor) observations about artifacts.
Feeds Structure: The concept of separate feeds for different issuers (e.g., an official vendor feed vs. a security researcher feed commenting on the same artifact) was proposed as a solution to balance control and transparency. This structure enables mutually distrustful parties to make observations.
Transparency Service Responsibility: There was a strong sense that the specific access control policies to prevent spam and vet submitters should be the responsibility of the transparency service operator, rather than being strictly defined in the SCITT standard. The standard should provide the necessary dimensions and mechanisms that can be leveraged.
Implementation Specificity: It was reiterated that robust access control mechanisms, while important for practical deployments, are implementation-specific and outside the direct scope of the SCITT core specification.
"Strict Model" Debate: A concern was raised that without a "strict model" where only authorized product owners can submit, SCITT could become a "spam magnet." While the standard should support such strict models, it was also argued that focusing solely on them might hinder the broader transparency goals.

IETF 117 Hackathon Aims

Pivot from Interoperable Registration Policies: Due to insufficient progress and the complexity of achieving interoperable registration policies at this stage, the working group agreed to shift the hackathon's focus.
Use-Case Driven Approach: The new aim is to demonstrate the usefulness of SCITT's building blocks through practical use cases.
FDA Medical Device Cybersecurity Use Case: Dick Brooks presented a detailed use case stemming from new FDA requirements (effective October 1st) for medical device manufacturers (MDMs) to submit SBOMs and related cybersecurity information.
- Vendor Response File (VRF): The proposed mechanism involves MDMs creating a digitally signed "Vendor Response File" (VRF) containing URLs and metadata for required disclosures (SBOMs, vulnerability reports, SDLC policies, commercial/support status, etc.).
- SCITT Integration: The VRF would be registered as a payload in a SCITT transparency service, which would issue a receipt/URL. MDMs could then provide this URL to the FDA, who would retrieve the VRF and subsequently download the referenced materials.
- Searchability and Scope: Discussion included the need for searchability within SCITT for VRFs (e.g., by vendor, product name) and how the VRF, while meeting official requirements, could also accommodate unmandated but relevant third-party observations or disclosures about product risks.

Decisions and Action Items

Decision: No consensus decisions on registration policies were made due to low attendance.
Decision: The IETF 117 hackathon focus will pivot from interoperable registration policies to a use-case driven demonstration of SCITT's usefulness.
Decision: The FDA medical device cybersecurity use case, utilizing a Vendor Response File (VRF), will be explored as a primary candidate for the IETF 117 hackathon.
Action Item: John (chair) will clarify the scope and definition of "feeds" within the SCITT architecture document to address current ambiguities.
Action Item: John (chair) will refine wording in the SCITT specification to articulate minimum requirements and expected outcomes, while avoiding over-specification of implementation-specific mechanisms for access control.
Action Item: Dick Brooks will coordinate with John regarding the FDA VRF use case for the hackathon and offered to contribute the VRF's XML schema to the IETF SCITT group.
Action Item: Roy to be included in upcoming discussions related to the FDA use case.

Next Steps

Continue discussions on registration policies, focusing on refining the terminology and scope of "feeds" in the SCITT architecture.
Actively plan for the IETF 117 hackathon, centering on the FDA medical device cybersecurity use case and the potential development of a generic Vendor Response File.
John and Dick will synchronize efforts on the VRF contribution and hackathon logistics.

Session Date/Time: 19 Jun 2023 15:00

SCITT

Summary

Key Discussion Points

Registration Policies

Definition and Scope: Initial confusion existed regarding whether a registration policy applies to the log as a whole, specific products, or feeds. It was clarified that SCITT aims to allow identification and access control at the feed level, not to restrict who can comment on a product.
Spam vs. Transparency: A core tension was identified between preventing spam and denial-of-service attacks on a SCITT service and the desire to allow security researchers, transparency advocates, or other third parties to make legitimate (though potentially unwelcome by a vendor) observations about artifacts.
Feeds Structure: The concept of separate feeds for different issuers (e.g., an official vendor feed vs. a security researcher feed commenting on the same artifact) was proposed as a solution to balance control and transparency. This structure enables mutually distrustful parties to make observations.
Transparency Service Responsibility: There was a strong sense that the specific access control policies to prevent spam and vet submitters should be the responsibility of the transparency service operator, rather than being strictly defined in the SCITT standard. The standard should provide the necessary dimensions and mechanisms that can be leveraged.
Implementation Specificity: It was reiterated that robust access control mechanisms, while important for practical deployments, are implementation-specific and outside the direct scope of the SCITT core specification.
"Strict Model" Debate: A concern was raised that without a "strict model" where only authorized product owners can submit, SCITT could become a "spam magnet." While the standard should support such strict models, it was also argued that focusing solely on them might hinder the broader transparency goals.

IETF 117 Hackathon Aims

Pivot from Interoperable Registration Policies: Due to insufficient progress and the complexity of achieving interoperable registration policies at this stage, the working group agreed to shift the hackathon's focus.
Use-Case Driven Approach: The new aim is to demonstrate the usefulness of SCITT's building blocks through practical use cases.
FDA Medical Device Cybersecurity Use Case: Dick Brooks presented a detailed use case stemming from new FDA requirements (effective October 1st) for medical device manufacturers (MDMs) to submit SBOMs and related cybersecurity information.
- Vendor Response File (VRF): The proposed mechanism involves MDMs creating a digitally signed "Vendor Response File" (VRF) containing URLs and metadata for required disclosures (SBOMs, vulnerability reports, SDLC policies, commercial/support status, etc.).
- SCITT Integration: The VRF would be registered as a payload in a SCITT transparency service, which would issue a receipt/URL. MDMs could then provide this URL to the FDA, who would retrieve the VRF and subsequently download the referenced materials.
- Searchability and Scope: Discussion included the need for searchability within SCITT for VRFs (e.g., by vendor, product name) and how the VRF, while meeting official requirements, could also accommodate unmandated but relevant third-party observations or disclosures about product risks.

Decisions and Action Items

Decision: No consensus decisions on registration policies were made due to low attendance.
Decision: The IETF 117 hackathon focus will pivot from interoperable registration policies to a use-case driven demonstration of SCITT's usefulness.
Decision: The FDA medical device cybersecurity use case, utilizing a Vendor Response File (VRF), will be explored as a primary candidate for the IETF 117 hackathon.
Action Item: John (chair) will clarify the scope and definition of "feeds" within the SCITT architecture document to address current ambiguities.
Action Item: John (chair) will refine wording in the SCITT specification to articulate minimum requirements and expected outcomes, while avoiding over-specification of implementation-specific mechanisms for access control.
Action Item: Dick Brooks will coordinate with John regarding the FDA VRF use case for the hackathon and offered to contribute the VRF's XML schema to the IETF SCITT group.
Action Item: Roy to be included in upcoming discussions related to the FDA use case.

Next Steps

Continue discussions on registration policies, focusing on refining the terminology and scope of "feeds" in the SCITT architecture.
Actively plan for the IETF 117 hackathon, centering on the FDA medical device cybersecurity use case and the potential development of a generic Vendor Response File.
John and Dick will synchronize efforts on the VRF contribution and hackathon logistics.