-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Streamline Safe Extensions section #34
Comments
I agree with your points 1 and 3. Point 3 is (I believe) already covered by Rohan's #31. On Point 2: I partially agree in that this section should live outside of Section 2, because it's useful for both safe and unsafe extensions. I don't think it should be removed, though. The purpose of these additional structs is to allow extensions authors to just request an extension code point, after which they can create any proposal/credential or WireFormat they like without requiring additional code points. It also makes negotiation simpler, as support for an extension always implies support for all proposals, etc. associated by that extension. If anything, this mechanisms improve the base extensibility mechanisms we have in MLS. |
Will be addressed with refactoring PR. |
I believe this is now addressed in #43 |
The Safe Extensions section currently has a bunch of unnecessary baggage, which we should rearrange and/or delete.
The core of what Safe Extensions needs to define is: What does an extension need to do in order to be considered a safe extension?
From that perspective, the sections on HPKE, signatures, export, and PSKs all make sense, in the sense that an extension is safe if the only HPKE/signature/export/PSKs mechanisms uses are the ones defined here. That leaves the "Security", "Extension Designer Tools", and "Extension Design Guidance" sections.
The text was updated successfully, but these errors were encountered: