**Session Date/Time:** 20 Mar 2024 05:00

```markdown
# keytrans

## Summary

This meeting focused on the Key Transparency (KT) architecture document, which has been adopted as a working group document. Brendan presented progress on the document since IETF 118, covering topics like seal sender integration, federation, lifecycle management (migration and pruning), compliance with privacy laws (GDPR), and privacy considerations related to user data and third-party auditors. The discussion revealed strong interest in developing a protocol document based on the architecture.

## Key Discussion Points

*   **Seal Sender (Anonymous Communication):** Discussed how KT can work with anonymous communication protocols like Signal. The need for an anonymizing proxy and the serialization of KT server interaction transcripts to act as credentials was presented.
*   **Federation:** Simple federation is possible using namespaced lookup keys (e.g., domain-based). Anonymizing proxies are recommended over mirroring other service providers' logs to protect user privacy and ensure data consistency.
*   **Lifecycle Management (Migration and Pruning):**
    *   **Migration:** Proposed prepopulating the new log with data from the old log and storing the old log's final root hash in the new log to ensure consistency.
    *   **Pruning:**  Separation of data into "user data" (application-knowable) and "cryptographic data" to allow pruning of old user data versions and associated cryptographic data.
*   **Compliance with Privacy Law (GDPR):** Discussed using anonymity by deleting data necessary to understand the log's content, specifically commitment openings related to user data. Using a VRF (Verifiable Random Function) for lookup keys and removing the proof to make it hard to reverse the mapping of random output bytes back to original phone numbers or emails.
*   **Privacy:**  Compared trade-offs between hiding the total number of users (better for service operators) and providing better privacy for individual users (by preventing correlation of updates). Padding the log with fake changes requires actual changes to the log which costs a significant amount of data.
*   **Log Failure Recovery:** Migration strategy works with a new log as long as you have the final root hash of the old log and can make read queries against the old log for some time. Read-only mirrors of a KT log would also solve this problem.
*   **Protocol Document Development:** Discussion emphasized the need to start developing a protocol document based on the architecture to address hand-wavy concepts.

## Decisions and Action Items

*   **Action Item:** Post a call for contributors to the protocol document on the mailing list, explicitly inviting those who expressed interest in writing or reviewing.
*   **Action Item:** Brendan will be the lead on writing the protocol document
*   **Decision:** Form a design team of willing contributors for the protocol document, to be coordinated after mailing list responses are received.

## Next Steps

*   Post a call for contributors on the mailing list, with an explicit distinction between those interested in contributing (writing) versus reviewing.
*   Form a design team based on the mailing list responses and start drafting the protocol document, led by Brendan.