**Session Date/Time:** 05 Nov 2025 21:00

# STIR

## Summary

The STIR working group discussed updates to RFC 8588bis and the STIR Certificate Transparency document, both of which are moving towards Working Group Last Call. A significant portion of the session was dedicated to an extensive discussion on the Vesper framework, focusing on its use cases, privacy considerations, and the role of business identity. Concerns were raised regarding the clarity of requirements and the IETF's role in policy versus mechanism development. A new Out-of-Band (OOB) extension proposal was also presented, prompting questions about its architectural implications. The chairs and AD emphasized the need to clarify the working group's charter and prioritize specific deliverables.

## Key Discussion Points

*   **RFC 8588bis Updates**: Proposed updates include fixing errata in the IET field, updating UUID reference, and revising the ADDIS 10 reference to point to an archived version on a joint activity website. A suggestion to change the UUID reference from "recommended" to "must/shall" was considered but ultimately rejected due to backward compatibility concerns and existing deployment practices.
*   **STIR Certificate Transparency**: The document was noted to be straightforward and largely ready for a Working Group Last Call, pending completion of its security considerations section, which was identified as having "to-dos."
*   **Vesper Framework**:
    *   The framework aims to bind Telephone Numbers (TNs) using delegate certificates, authority tokens (TNAuthList, JWT claim constraints), and transparency mechanisms, along with connected identity concepts.
    *   **Use Cases and Privacy**: Extensive discussion, led by John Peterson, highlighted the need for concrete use cases (B2C, C2B, B2B) and a clear threat model for any proposed privacy constraints. The question was raised about what information is being protected, from whom, and how it would be disclosed to necessary parties.
    *   **Business Identity**: The proposal to include explicit connections to business site identity (e.g., via Spice/GLUE) for calling parties was debated. John Peterson questioned whether such information, if related to certificate issuance, should be a certificate extension rather than a passport claim, arguing it is invariant per call.
    *   **IETF's Role**: Russ Housley (AD) reminded the group that the IETF's role is to build "sprockets" (technical mechanisms) that support potential policies, rather than defining the policies themselves.
    *   **Document Strategy**: Orie Steele (AD) expressed a preference against adopting a protocol document solely for discussion. He suggested focusing on use case and requirements documents if the group wishes to explore additional cryptographic mechanisms or fields for passports/certificates.
*   **Out-of-Band (OOB) Extension**: A draft proposing an optional extension with URIs for Call Placement Service (CPS) in certificates/delegate certificates was presented. John Peterson raised concerns about the security implications if the certificate determines the CPS location, and the broader architectural model of data collection and trust.
*   **STIR CT Log**: An idea for Certificate Transparency (CT) monitors to extract and cache delegate certificates for lookup was discussed. This was compared to the "chicken and egg" problem previously encountered and the potential for a large number of delegate certificates to overwhelm such a system, effectively requiring the pushing of all certificates to relying parties.
*   **Post-Quantum Cryptography**: A brief discussion touched on whether STIR should begin considering Post-Quantum (PQ) cryptography, noting that the short-lived nature of passports might make PQ implications less urgent.
*   **Charter Re-evaluation**: The chairs and AD indicated that discussions around Vesper highlighted a need to tighten and modernize the STIR working group's charter, making it more concise and specifying known deliverables.

## Decisions and Action Items

*   **RFC 8588bis**: The document was adopted as a working group document.
    *   **Action Item**: The document shepherd (Mary Barnes) will submit a new version.
    *   **Action Item**: The chairs will initiate a Working Group Last Call for RFC 8588bis once the updated version is submitted, possibly simultaneously with adoption.
*   **STIR Certificate Transparency**:
    *   **Action Item**: The document editor will update the security considerations section to address the identified "to-dos."
    *   **Action Item**: The chairs will initiate a Working Group Last Call once the updated version is posted.
*   **Vesper**: The working group will focus on developing use case and requirements documents for the Vesper space, rather than a protocol document initially.
    *   **Action Item**: Chris Wendt will reach out to John Peterson and others interested in working on Vesper use cases and requirements documentation.
*   **Working Group Rechartering**:
    *   **Action Item**: Discussion on desired deliverables for a new, tighter STIR charter will commence on the mailing list.
    *   **Action Item**: If mailing list discussion is not fruitful, an interim meeting focused on rechartering will be held.

## Next Steps

*   Submit updated drafts for RFC 8588bis and STIR Certificate Transparency.
*   Initiate Working Group Last Calls for both RFC 8588bis and STIR Certificate Transparency.
*   Begin discussions on the STIR mailing list regarding the rechartering process and specific deliverables.
*   Form a sub-group or collaborative effort to draft use cases and requirements for the Vesper framework.