Streamline Safe Extensions section

[bifurcation]

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.

• "Security" should just be the introduction to the Safe Extensions section.
• "Extension Designer Tools" should be deleted. The mechanisms here abuse the extension types for labelling things other than extensions, and they don't really provide any value over the base extensibility mechanisms they use. At best, they provide "ignorable" objects of the various types, which is a totally different property than Safe Extensions provides.
• "Extension Design Guidance" is not specific to Safe Extensions. It should be promoted to its own top-level section.

[kkohbrok]

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.