Agenda review  
WG I-Ds Status for Architecture   
 Currently past the IESG Review

<Richard Barnes="">
    MLS Protocol 
        Draft 18 major change was GREASE approach. Published draft and then found/corrected errors associated. 
        Draft 19 minor - corrected errors and other minor changes
        Interoperability: 6 different implementations (half open sourced) - c++, java, etc. Two styles of interop testing: Shallow Test and Deep tests. Shallow tests is about testing on your own test vectors. Deep tests are using sets of premade tests that cover a wider breadth of interoperabiltiy testing. MLS and Wire are leading way in the implementations and interoperability tests.
    Off to the RFC Editor! 
    <Sean> Please keep track of the interoperability tests and standardization as we move forward </Sean>
    <Sean> Putting a pin in architecture discussion. </Sean>

</Richard>

<Raphael> MLS Extensions and Federation 
    Federation document that's stable and waiting for MIMI to better position it. 
    <Richard> 
        There may be some non-MIMI use cases where having a standard API would be useful. 
    </Richard>
    Extensions 
    - More IANA registries - flexible wire formats, lables, signatures, public key encryption)
    - Content Advertisement extension (proposed as a standalone extension that made it into the draft by Rohan)
    - Group anchors draft (also Rohan)
    - Safe Extensions - give guidance on how they should be structured and security implementations 
    (Joel, Marta and Raphael)
    
</Raphael>

<Jöel> Safe Extension APIs 
    Only interacts with MLS group with this API. No Safe Extension will harm security properties of vanilla MLS. Safe Extensions cannot interfere with each other and you can analyze them in isolation: the security properties can be composible with each other. 
    Examples of Safe Extension: 
        - RBAC (Role Based Access Control) for MLS 
        - Cryptographic agreeement on application data 
        - Safely exposing some keys (giving an interface to the keys for higher level applications). Forces key separation. 
        - PQ with flexible classic/PQ overhead tradeoff. E.g. PQKEM - interleaving PQ updates 
        - Application triggered custom event injection into MLS session
    Extensions are registered through IANA - API will take care of the separation. Perhaps a ticket in the IANA registry for every safe extension - like a criticality flag. 
</Jöel>

<Raphael> 
    We can either do a separate draft for safe extensions or PR toward extensions document. 
</Raphael>

<Rohan> 
    More MLS Extensions 
Content Advertisement (in draft-ietf-mls-extensions)
        **Needs feedback 
    Express media types that are supported in leaf/nodes in group and in KeyPackages
    Express required types in GroupContext
    Express the media type inside an application message
    (These are accepted IANA media types )
    - Application Framing 
    **PLEASE PROVIDE FEEDBACK for Content Advertisment draft since MIMI will be churning on it**
    
    
    Multi-party Alternative: Consider carefully to see if it's useful to keep and how clients will be using it. (i.e. alice supports html and bob only supports markdown in a 20 member group)
    
    
~ Trust Anchors ~
    
    Problem: We're doing federation with MLS and we want to start using Identity certificates for user identities. We need trust anchors to validate identities but we don't want to trust the intermediate trust anchors in all the federated domains we're working with. We need to avoid one federated domain impersonating identities in another. 
    
    Solution: GroupContext Extension witha list of domain/certchain pairs. We can now validate identities of different domains with different certchains. 
    <Richard Barnes=""> 
    Definitions issue with validation rules per domain. We might need more definition on how a leaf node gets marked with their associated domain.
    </Richard>
    
    <Eric> 
        What happens when a node's cert gets updated? The associated certchain would be invalid now...certchain evaluation is very brittle to construct
    </Eric>
    MLS allows anyone to update GroupContext extensions so when certchain needs to be updated, it can be updated accordingly. 
    
    Would be nice to use a hash for certchains. 
    <Sean> There's an extention called HashOfRootKey that may be useful for this </Sean>
    **Look into SPKI alternatives 
    
    ~ The Leaving Problem ~
    Inablity of client to remove themselves without consensus of the group. Comes from not being allowed to process pending proposals if they don't arrive before a commit or gets overriden by other proposal that arrives sooner. 
    
    Define a new Leaving Proposal signed by the leaving member. 
    1) Clients sending a commit with Leaving Proposals must include them. Includes external joiners (must get Leave Proposals with GroupInfo).
    2) New Leave proposal can be included in External Commit, and external commiter can verify the signature 
    3) Clients about to send an application message, send Commit if any Leave proposal is pending. 
    <Raphael> #3 is already taken care of by MLS mechanism of must commit before sending new proposals? Introducing this Leaving Proposal changes security of MLS. </Raphael>
    
    **A draft of Leave Proposal is needed to further evaluate the security implications. 

    
    Machine Readable Policies in GroupContext? Provably agree on these parameters? 
    
</Rohan>