Hi Matt,

Thanks for putting this proposal forward. I think it's a really interesting one, worth digging into properly.

I can definitely see the upside. In particular, this could be a good signal of maturity for the XMPP ecosystem. It might also help with coordination around vulnerabilities, especially when issues span multiple implementations or touch protocol-level behavior. I think we're already doing some of that mostly informally, but having a clearer, more consistent "home" for XMPP-related CVEs seems like it could make things easier for both maintainers and security researchers.

That said, I think there are a few important concerns to work through.

The biggest one for me is the operational workload. Even if the number of CVEs is relatively small, this is still an ongoing responsibility that needs reliable attention and follow-through. I don't think it's realistic or healthy to assume this could just be handled by a single volunteer long-term (Matt or anyone else). If we go down this route, we'd really need a proper team and a sustainable setup around it, not just informal goodwill.

Closely related to that is a liability / expectation shift. Even if CNA work is technically voluntary, it creates external expectations around response times, consistency, and correctness. That loops back into the workload issue and makes it even more important that we're honest with ourselves about what we can actually commit to.

There's also a fair bit of complexity and ambiguity around scope. Is a generic library (like an XML parser used by a client) in scope? What about components that we don't consider to be XMPP project, but have some kind of XMPP-based interface? Forks? Abandoned projects?  

Lastly, I think following through on this would subtly change how the XSF governance stance is perceived: from being "just" a standards body to also acting as a security authority for part of the ecosystem. That's not necessarily bad, but it does mean we should be careful about transparency in how decisions get made. There may be neutrality concerns if the XSF is seens as 'judging' implementations.

Overall I'm positive about exploring this further. I think a key missing piece right now is a clearer picture of what the operational model would actually look like in practice, and how tightly we define the scope so this doesn't turn into either overload or ambiguity.

Also very interested in what others think, especially from people who've actually done CNA work or coordinated vulnerability disclosure before.

Thanks again for putting this forward Matt - I think this could be very valuable to explore.

Kind regards,